Summer of Code Update

Time for an update on my progress with my project, now we are halfway through GSoC...

Disconnection (either by error, or as requested by the gloox client) gracefully from the server is working now. I have also made some small improvements in other areas where necessary, too many and too small to list here.

A big problem I am having is that there are regular delays in my test setup. I have a test client for gloox that replies to messages it receives. I have tried both tkabber and Psi as the second client, with the same results.

I checked that my BOSH code is doing everything correctly and it seems the answer is (insert disclaimer here) yes.

Here is the link to a network capture log: Wireshark capture file

The file is so named because the test message I sent was the text "ooo". (No, I don't know why...)

Below is my translation to English of the necessary parts of the log, showing a message going from Psi to gloox (via the server) and the reply going back again:

A: GUI client (Psi 0.10, port 32921->5222)
B: BOSH client (gloox svn, port 45069->5280)
S: Jabber server (Openfire 3.3.2, port 5222)
CM: BOSH connection manager (Openfire 3.3.2, 5280)

# GUI client sends message to server
0 sec: A->S (frame 37 in the capture)
0.000030: TCP ACK for the above

# Server sends message to gloox via BOSH
0.001999: CM->B

# Gloox sends composing event
0.003065: (Composing event) B->CM
0.003090: TCP ACK for the above

# Gloox immediately after this sends reply message
0.003358: B->CM
0.003370: TCP ACK for the above

# Server sends composing event to GUI client
0.004707: (Composing event) S->A
0.004725: TCP ACK for the above

# Server replies with empty response to gloox,due to 30s inactivity (as per spec)
30.007330: (Empty response) CM->B

# Server sends message to GUI client
30.012078: S->A

# All the acks for the last packets
30.012078: TCP ACK for last TCP ACK (RTT to ACK was 30.007 seconds) (??????!)
30.012106: TCP ACK for S->A
30.046637: TCP ACK for (Empty response) CM->B

If anyone could explain why the server appears to hold a message for 30 seconds, please let me know!

The story with ejabberd (which I finally managed to patch, compile and build) isn't good either. Because the new version of the BOSH XEP does not define how to restart a stream, XEP-0206 support is needed, which now defines this function. Unfortunately no server supports this yet, so I disabled SASL until I find a way around this. Unfortunately ejabberd forces clients that advertise XMPP 1.0 to use SASL (which gloox does) so it denies login attempts.

Detecting which version of the BOSH protocol is supported by the server, and using the old method when necessary would work in this case, but not in Openfire's (it reports version 1.6 already).

There are a few server-independent connection managers around, and I will test with those. My intention is to find one that I am able to bring up to date with the current specifications.

This is my focus at the moment, but very soon I will begin implementing multiple connections (a big step) for when pipelining can not be used.