Le Wed, 13 Aug 2008 12:58:10 -0600, Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :
> Alban Crequy wrote: > > Hi, > > > > In a link-local conversation with XEP-0174, a client A sends the > > ending stanza to the other end's client B: "</stream:stream>" > > > > http://www.xmpp.org/extensions/xep-0174.html#end > > > > After that, B continues to send message stanzas to A but never sends > > the ending stanza. The ending stanza from A is ignored by B. > > Why? The closing stream tag is ignored just for the purpose of my scenario ;-) But I agree this is a bug in the client B (and in the XEP because there should have been a "MUST"). > > The > > XEP-0174 seems to say B has to close the stream but there is no > > "MUST" or "SHOULD". > > I think that's supposed to be a MUST. The text "the other party then > closes the stream in the other direction as well" is not good > specification language. I agree. > > When the user of A wants to send a message, A can't send it using > > the current connection because the ending stanza has already been > > sent on this connection and sending stanzas after the ending stanza > > is obviously not correct. The client A cannot closes the TCP > > connection while it did not receive the ending stanza from B > > because it may miss a message. > > I think that A can indeed close the TCP connection, but will miss > some messages. Indeed, we might want to say that A sends > </stream:stream> and closes the TCP connection immediately. I would prefer the XEP to say that the client A MUST wait the closing stream tag from B before closing the TCP connection and MUST handle message stanzas from B correctly, so no message will be lost. It is possible (with network latency) that theses message stanzas are sent by B before B is notified that A want to close the stream. I even propose that, when B receives the ending stanza from A, B can still send the remaining messages it may have to send from its queue and sends the closing stream tag after, as soon as it has nothing to send. > > The XEP does not say whether A should open a second stream or should > > wait the first stream to be closed by the remote end. The second > > option seems better to me, > > Agreed. If we want the XEP to say there can be only one stream between two clients, we should define the correct behaviour when two clients initiate a TCP connection to each other at the same time. Do we want one connection to win and the second to be closed? > > but in this case B MUST closes the stream at some > > point when A sends the ending stanza (otherwise, A's messages will > > never be sent). > > Also agreed. > > > It seems that iChat behaves like the client B in my scenario, i.e. > > it does not close the stream when it receives the ending stanza. > > This causes problems when the client A waits the connection to be > > closed in order to open a new one. > > I think we hadn't considered the complexities here when we first > documented serverless messaging. The fact that clients can get in > this state is a problem -- i.e., the state where A won't send stanza > to B and does not expect stanzas from B, but B ignores A's stream > close and continues to send stanzas to A. I consider this a bug in B, > and I think we need to clarify the spec so that B sends a stream > close as soon as it receives a stream close from A. > > We probably also need to define how a client needs to handle stanzas > it receives after it sends the closing stream tag (ignore them? show > them to the user?). If a client receives stanzas after it has received the closing stream tag, that's a bug in the remote client because it is not allowed to send something after closing the stream. But a client receives stanzas after it sends the closing stream tag, the client must show them to the user because the remote client has no way to know that the client sent the closing stream tag (with some network latency). -- Alban
