You are here

Stream Compression

While implementing stream compression I noted it says that "Negotiation of stream compression SHOULD be completed before authentication via SASL". This is also the way ejabberd 1.1.2 and OpenFire 3.3.2 works.

However, in XEP-0170: Recommended Order of Stream Feature Negotiation it says that SASL should go before compression. Total confusion! A quick post to the jdev list this was sorted out; XEP-0138 didn't get updated when XEP-0170 was discussed. No big deal. But OpenFire also accepts compression after SASL which is according to XEP-0170. In an attempt to serve two ways, it continue to offer SASL even after the process SASL -> compression, which I believe is a bug.

Talking of bugs, it took some effort to figure out how to use zlib for streams, but a TIP, Add Support For Zlib Compression seems to have fixed it, except for one thing: it bails out when I try to send any non 7 bit characters, and the non 7 bit characters I get are crumpled. Under investigation.

Comments

Have you done some extensive testing with stream compression with an OpenFire server? (i.e. run the client for a while with compressed streams). If so, did you experience any problems?
Apparently, some clients seem to have problems ever since OpenFire enabled compression again, where these clients worked perfectly with earlier Wildfire versions.

I haven't done any extensive testing with OpenFire since I have a so far unsolved encoding issue. However, I had a bug when sending keep-alive newlines every 30 secs where the server shut me down. It turned out that the newlines were sent as newlines on the socket and didn't get compressed via the zlib stream. When I sent the newlines through the zlib stream it worked as expected. Perhaps these clients are experiencing a similir problem, and that OpenFire didn't react on these "illegal characters" in its previous version?