[JDEV] GZipping Jabber Messages

Max Metral Max.Metral at PeoplepcHQ.com
Fri Jan 4 16:46:09 CST 2002


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



More information about the JDev mailing list