[JDEV] GZipping Jabber Messages
Michael F Lin
MFLIN at us.ibm.com
Fri Jan 4 22:21:08 CST 2002
We could use ASN.1 to rewrite the XML markup in a terser format, and
probably we'd do about as well as gzip for much less processing power. This
would do darn well for presence tags which tend to be highly regular. But
ASN.1 wouldn't really help us for arbitrary message or iq payloads which
are hopefully where we spend most of our bandwidth (this is a risky
conjecture - I know). Then again, on a per-packet basis gzip doesn't seem
to really help much either (pending more tests).
So ASN.1 or any similar binary dictionary encoding of our XML could save us
some bandwidth, more efficiently than gzip, but I guess it would be a hard
sell to show that this is worth the more difficult implementation and
ambiguity that would result from effectively having two different wire
protocols...
-Mike
Max Metral
<Max.Metral at peopl To: "'jdev at jabber.org'" <jdev at jabber.org>
epchq.com> cc:
Sent by: Subject: RE: [JDEV] GZipping Jabber Messages
jdev-admin at jabber
.org
01/04/2002 05:46
PM
Please respond to
jdev
Seems to me you'd probably save a lot more, in aggregate, by encoding the
tags in a standard notation (i.e. the ASN.1 comment I made before) rather
than the payload. A token-y, session long (or server global) scheme would
be a lot lower processing overhead and save a ton of bandwidth.
XML was never meant to be bandwidth sensitive, in fact has almost the
opposite as a goal. But it's still great for what we're using it for in
general. A transparent (servers would support both) optimization only
would
make sense.
-----Original Message-----
From: Julian Missig [mailto:julian at jabber.org]
Sent: Friday, January 04, 2002 5:31 PM
To: jdev at jabber.org
Subject: Re: [JDEV] GZipping Jabber Messages
It's not really defining a binary transport layer, it's just gzipping
the stream. They're looking for something less processor-intensive than
SSL, I imagine.
You can argue the merits of it when/if it comes up as an official
extension/replacement for bits of Jabber via a JEP. Until then, unless
you have a better suggestion, I think they're pretty much free to play
with want they want. Maybe they'll figure out something that would be
worth writing up a JEP for. Maybe not. Official Jabber won't contain it
until they write up a JEP, so there's no need to worry.
Julian
--
email: julian at jabber.org
jabber:julian at jabber.org
Michael F Lin wrote:
> Is this in parallel to how SSL works with encryption or does SSL do
> compression already? If so then lets just use SSL. If not, then I find
the
> idea of defining our own binary transport layer a bit unsettling. We're
> talking XML, we should be above all that ;-)
>
> -Mike
>
>
>
>
> Julian Missig
> <julian at jabber.or To: jdev at jabber.org
> g> cc:
> Sent by: Subject: Re: [JDEV]
GZipping Jabber Messages
> jdev-admin at jabber
> .org
>
>
> 01/04/2002 04:57
> PM
> Please respond to
> jdev
>
>
>
>
>
> Nah, I think they're talking about gzipping all of the data, sending it,
> and ungzipping before sending it to the XML parser on the other side,
> just like SSL works.
>
> Julian
> --
> email: julian at jabber.org
> jabber:julian at jabber.org
>
> Michael F Lin wrote:
>
> > Keep in mind that the gzip data would have to be base64 coded, which
> > would increase its size by 33%. So you can run the statistics and
> > figure out how long your payloads have to be to get better than 33%
> > compression ratios with gzip, but I imagine it is quite long
> > relative to the average since of a Jabber packet
> > (message/presence/iq).
> >
> > -Mike
> >
> >
> >
> >
> > Adam Theo
> > <adamtheo at theoret To: jdev <jdev at jabber.org>
> > ic.com> cc:
> > Sent by: Subject: [JDEV] GZipping Jabber Messages
> > jdev-admin at jabber
> > .org
> >
> >
> >
> > 01/04/2002 03:32
> > PM
> > Please respond to
> > jdev
> >
> >
> >
> >
> >
> >
> > Hi, all. There's a good discussion going on over at the DotGNU
> > Developer list about gzip'ing the XML that is transmitted around on
> > the DotGNU platform.
> >
> > Was wondering if it would be possible to incorporate the same thing
> > for future versions of the Jabber server? Is it feasible, anyway?
> > They are saying the trade-offs for extra resource consumption would
> > not be bad at all if designed into the server properly, and would
> > reduce bandwidth very dramatically (like by 80%, i think). This
> > would be useful for high-volume servers with enough processing
> > power, i think...
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev
More information about the JDev
mailing list