[Standards-JIG] XMPP bandwidth compression

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Wed Jun 30 22:13:15 UTC 2004


have all thought about releasing the specification of exactly how you did it so that we can all make use of it so our systems are interoperable?

What does everything think about starting up a small working group to small definitely the XMPP compression problem? 

I would think we would need to either update the XMPP:Core RFC or add it to the XMPP End-to-End Encryption RFC (which might be easier).

Peter, what do you think?

boyd


> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of 
> Jean-Louis Seguineau/EXC/ENG
> Sent: Wednesday, June 30, 2004 5:50 AM
> To: standards-jig at jabber.org
> Subject: Re: [Standards-JIG] XMPP bandwidth compression
> 
> Joe,
> 
> You've certainly expressed it better than I could. This is 
> just what we do, but in java ...
> 
> Jean-Louis
> 
> P.S. Funny how often we think along the same lines :)
> 
> -----Original Message-----
> 
> Message: 9
> 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).
> 
> 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
> 
> 
> ------------------------------
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 
> End of Standards-JIG Digest, Vol 5, Issue 31
> ********************************************
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 



More information about the Standards mailing list