[Standards-JIG] XMPP bandwidth compression

Joe Hildebrand hildjj at gmail.com
Fri Jul 9 15:44:44 UTC 2004


So after all the back-and-forth about this, stpeter is writing up a
JEP.  Once we have something that we like, we can take it to the XMPP
Working Group, and let them decide if they want to take it on.

Based on some quick-and-dirty testing I did on a limited corpus, I was
able to achieve at least a 6x compression using just plain old zlib,
with a partial flush after every stanza.  I'm working on getting a
larger corpus of real-world data, so I can ensure that these results
are indicative.

However, I'd say that zlib is good enough to start with, and other
compression (or binay encodings, or whatever) methods can be
negotiated using the same approach if people want to define those
later.


On Wed, 7 Jul 2004 18:21:38 -0400, Bob Wyman <bob at wyman.us> wrote:
> Stephen Pendleton wrote:
> >It seems to me that for the feature negotiation JEP-0020 is useful:
>         I think this would not be ideal. The problem is that to use JEP-0020
> you must have already opened up an XML Jabber stream and then you have to
> suffer the overhead of the JEP-0020 roundtrips to negotiate with the server
> to get a new non-XML stream. Even if the roundtrip costs are ignored, you
> are still faced with the problem that upon completing the JEP-0020
> negotiation you will have an open XML stream which must be closed and
> reopened before you can push non-XML data over the link.
>         Personally, I think that if non-XML streams are supported as
> alternatives, then the request for such a stream should be part of the
> stream initiation. The server would then respond either with an XML stream
> (the default and the fallback), which all clients should be required to
> understand, or stream using the requested alternative encoding (something
> like Fast Infoset). This avoids the negotiation roundtrips as well as the
> problem of closing the XML stream and opening a new alternative format
> stream.
>         Note: For this to work properly and to ensure that interop is not
> compromised, it is important to insist that "Jabber/XMPP compliant" systems
> must always be capable of supporting the XML format. (Clients that were so
> constrained that they simply can't support XML should at least be required
> to recognize that their request for an alternative stream format was
> rejected and be capable of closing the stream, using normal text-based
> Jabber XML, once they discover the rejection.
>         Given that the method I outline above impacts stream initiation, I
> think it would be necessary to do this as an extension to XMPP rather than
> as JEP although a JEP might be used for experimental purposes until the
> entire process was understood, debugged, etc. and an RFC could be put
> through the system.
> 
>                 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