XMPP and Compression: a little experiment

2009-06-05 23:54:04 by Fabio Forno

Zlib compression can reach very high compression rates with XMPP (up to 90%), however starting a session with a mobile client can be still expensive. The best solution would be less greediness of carriers, but I'm not dealing with science fiction, so I prefer to reduce data ;) These are the rough figures about a login with my roster (~250 contacts, with ~60-70 online) and with compression enabled using Lampiro:

  • ~ 1.5KB for the authentication and  stream setup
  • ~ 12-13KB for the presence broadcast and other related stanzas 
  • ~ 4KB for roster retrieval

Can we do better? There is a new proposal, Stanza Interception and Filtering Technology (SIFT ), which may help a little by filtering incoming stanzas and allowing session "hush". Which is the importance of hush, besides not receiving unecessary presence updates? As Dave Cridland pointed out in a private chat it can improve Zlib compression by stuffing more data during hush and delaying flushes. The question was: how relevant is this action? So I did few experiments with a log of a login of mines and these are the results:

  • A complete login session:
    • Initial data size: 136175
    • Compression of the whole block 16036
    • Compression flushing each packet 22739
  • Only presence:
    • Initial data size:55729
    • Compression of the whole block 4881
    • Compression flushing each packet 7323

 Almost 1/3 of bandwidth gained, SIFT is definitely good!

 

2 Responses to "XMPP and Compression: a little experiment"

  1. Niklas says:

    Have you considered using Efficient XML Interchange or similar? (http://www.w3.org/XML/EXI/)

    1. Fabio Forno Says:

      Periodically EXI pops out among the options, however we never went on for practical problems: - EXI (and any other binary XML serialization defined so far we are aware of) seems not to be particularly fit to XML streams, but more document oriented - EXI, if I got it well, is Zlib + XML reorganization in order to improve compressor performance; the idea is intriguing and benchmarks promising, however in mobiles we live in world of tradeoffs and this adds too much complexity (and CPU cycles, which mean shorter batter life)

      Leave a Reply

      Not logged in. You have to fill the data below to leave a post. Please register here

      Nickname:

      Email:

      Antispam code:

      XHTML: You can use these tags: [ a abbr acronym b br blockquote code pre em i strike strong ]


      To send a trackback, use this url.