[Standards-JIG] XMPP bandwidth compression
bob at wyman.us
Mon Jun 28 19:07:10 UTC 2004
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...
More information about the Standards