Hi,

I have recently been tackling a problem with a BOSH connected chat client
as follows:

1. Client requests a connection, with rid 12345
2. Server has nothing to send so holds the connection open
3. Connection is broken for some reason
4. Client re-requests connection with rid 12345
5. Server still thinks that rid 12345 is an active connection (basically
the client has re-requested it _before_ the server has realised there's a
problem)

XEP-0124 mentions that the client can re-request a previous request
(section 14.3) and this is just a corner case of that, so I'm thinking it
may be worth adding a note to the XEP to address this condition and
formalise the server's response (I.e. The server receives a re-request for
a rid it has already received, but not yet responded to)

The solution I have currently implemented is (if a request comes in with a
rid which the server thinks is still active and hasn't yet responded to)
to:

* Respond immediately to the existing connection, even if the wait time
hasn't yet passed (this will probably be an empty response)
* Respond immediately to the new connection with the same response (as per
section 14.3)

So the flow is:

1. Client requests a connection (conn #1), with rid 12345
2. Server has nothing to send so holds the connection open
3. Connection is broken for some reason. The client has realised but the
server hasn't.
4. Client re-requests connection (conn #2), with rid 12345
5. Server responds immediately to conn #1 with an empty response
6. Server responds immediately to conn #2 with an empty response
(duplicate response from 5.)
7. Client requests a connection (conn #3), with rid 12346
8. Server has nothing to send so holds the connection open
(And it carries on as per usual)



Alternatives to this may be:

* The server responds to the existing connection with some kind of error
condition, and for the new connection to pick up the long poll from there

* Leave both connections open (but then the server will need to respond on
both connections if a message comes in for delivery to the client)

Any thoughts very much appreciated. I just thought it would be good to
formalise the server behaviour in this condition.

Thanks,

Ashley Ward


Reply via email to