Packet Delay When Using Compression

Smack Smack Dev
1

I am developing a custom client and just upgraded to Smack 3.0 beta 3 from a previous nightly build of Smack 3.0 and noticed that there is a problem with outgoing packet transmission. After some troubleshooting, I have isolated the problem to only occurring when compression is enabled. When I set my presence or send a chat message the Smack debug window shows the correct XML in the “Sent” area, but Wildfire never shows a change in presence and consequently neither does Exodus. Each time I change my presence again, then the previous packet goes through to Wildfire and Exodus. If I wait for a while, the first packet will also eventually go through. Based on this observed behavior, my guess is that the compression feature is buffering a stream of data and isn’'t sending it until a certain threshold is reached. Therefore, sending more data makes it work and waiting allows the heartbeats to fill up the buffer as well. With compression off, everything works fine. Compression also worked fine for me before upgrading. Has anyone else tried to use compression with the latest build?

System information: Wildfire 3.2.4, Java 1.5.0_10, and Windows XP SP2.

Thanks,

Chris

2

Chris,

Hmm, strange issue. Have you tried out Smack 3.0.0 yet? I know we changed one subtle thing about the compression flush mode that we use recently, but I’‘m not sure it will solve the issue you’‘re seeing. XMPPConnection (around line 944) is what sets up the connection stuff. I even dug around in the JZLib code a bit and don’‘t quite see what the issue is. I think it might need to buffer a certain amount before it can apply the compression? In any case, hopefully 3.0.0 solves the problem for you. If not, we’'d have to dig more.

Regards,

Matt

3

Thanks Matt.

Sure enough, Smack 3.0.0 fixes the issue. The latest version is looking good so far.

4

Awesome, glad to hear that did the trick.

-Matt