On Mon, May 21, 2012 at 12:39 PM, Ashley Ward <[email protected]> wrote: > 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.
I don't know how others feel about this, but I suspect the right thing to do when re-receiving a RID is to junk the previous connection and reply on the new one. Any client sitting at the other end of the old connection is either broken or has suffered a network issue. /K
