On Thursday 08 November 2007 1:26 am, Fabio Forno wrote: > On Nov 8, 2007 9:52 AM, Tomasz Sterna <[EMAIL PROTECTED]> wrote: > > Dnia 08-11-2007, Cz o godzinie 00:29 +0100, Fabio Forno pisze: > > > One of the reasons I tend to use id bosh is the ability of keeping the > > > session open when the client temporary disconnects > > > > XEP-0198: Stanza Acknowledgements already supports session recovery > > after disconnection with <reconnect/> element. > > It also ensures, that no packets get lost with the connection failure. > > Too many xeps, sometime sou get lost ;) Yep it seems to work also for > tcp connections, there is a thing I cant understand: when the > initiating entity tries to recover from a packet of a previouos > session, how do the server choses the correct session if the <bind/> > of the resources and stanzas acks are offered together? I mean: in the > unlucky case of an entity having two open sessions and losing both of > them, how can the server decide which is the session to recover, but > adding some semantics to the ids?
When you connect again, you specify the ack session id of the disconnected connection, so that the server knows which session you are trying to recover. According to the XEP, you then would do resource binding. At the very least, the XEP should be updated to state that the client must bind to the same resource as before, and if it doesn't then the server must assert the correct resource in the bind iq reply. However, I'm tempted to say that when you resume an ack session, the resource binding step should just be skipped. After all, both parties already know what the resource is supposed to be. -Justin
