[Standards-JIG] XMPP bandwidth compression

Joe Hildebrand hildjj at gmail.com
Tue Jun 29 00:08:48 UTC 2004


Why wouldn't a fairly-stock compression algorithm compress XMPP
nicely?  *Lots* of repeated tags, namespaces, etc.

I can imagine using zlib to do streaming compression.  Call
Z_FULL_FLUSH or Z_SYNC_FLUSH after each stanza.  As a matter of fact,
we could define a stream feature that did just that, with no TLS. 
Negotiate zlib compression, and start a new stream.  Call Z_SYNC_FLUSH
after the stream:stream on each side, and then after each stanza (or
series of stanzas, if you know you're going be sending many at once).

ref: http://www.gzip.org/zlib/manual.html

It's important not to use something like wbxml
(http://www.w3.org/TR/wbxml/) since in order for the compression to be
good enough, you have to know all of the potential schema at the
beginning of the stream.  Extensibility would suffer greatly.

On Mon, 28 Jun 2004 15:07:10 -0400, Bob Wyman <bob at wyman.us> wrote:
> Boyd Fletcher wrote:
> > One problem would be for those users who do not want to or can
> > not use TLS. Sometimes the TLS overhead both in extra data sent
> > and the reconnect problems can be too much.
>         Whether or not TLS is available, this approach is probably not the
> best for Jabber/XMPP use anyway.
>         The problem is that compression is expensive and often can't deliver
> useful results on small payloads. Thus, in a mixed use Jabber connection,
> where you're like to have both tiny chat packets like "brb" as well as large
> PubSub.com packets that send entire news items, you're going to end up
> increasing the size of your chat packets while decreasing the size of the
> large packets. The tradeoff might not, however, be positive. Also, the
> per-packet cost will increase because of the compression costs. Compression
> costs, combined with the cost of doing TLS encryption (if desired), might
> make the cost of preparing packets prohibitive. You should also consider
> that most compression schemes will prevent you from doing "streaming" use of
> data (i.e. working with partial results rather than buffering everything
> before you do anything with even the first bytes in a message.)
>         The problems of high-transaction rate servers are not quite so
> simple that they can be solved by simply saying: use RFC 3749...
> 
>                 bob wyman
> 
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 




-- 
Joe Hildebrand



More information about the Standards mailing list