[Standards-JIG] XMPP bandwidth compression
jean-louis.seguineau at antepo.com
Wed Jun 30 09:49:42 UTC 2004
You've certainly expressed it better than I could. This is just what we do,
but in java ...
P.S. Funny how often we think along the same lines :)
Date: Mon, 28 Jun 2004 18:08:48 -0600
From: Joe Hildebrand <hildjj at gmail.com>
Subject: Re: [Standards-JIG] XMPP bandwidth compression
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <82777bea0406281708644db513 at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
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).
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
> 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
> 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.
> 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
> 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
Standards-JIG mailing list
Standards-JIG at jabber.org
End of Standards-JIG Digest, Vol 5, Issue 31
More information about the Standards