On Monday 06 September 2010 07:13:44 Sergei Golovan wrote: > Hi! > > I'm rereading XEP-0047 (In-band bytestreams) and it seems to me that > the way a stream is supposed to be closed (section 2) doesn't play > well with bidirectionality (section 3). > > Consider scenario when a bidirectional stream is open, the first party > has sent all its data. So, it's natural to send closing stanza. After > that the remaining data from the second party will be lost because the > stream has to be considered invalid after closing it by one side. > > In theory the other side may just delay the answer to the closing > stanza and send all remaining data first, but it seems to be a bit > ugly to me (I don't like long delays between a request and a response > to it). > > So, are my concerns real, or I missed something obvious?
You are correct, but I don't think this is unusual behavior. Even with most TCP APIs, it is assumed that when you close a socket you will not be receiving further incoming data (unless you do one-sided shutdowns, which are obscure). So, ensuring all data gets exchanged near stream-end with IBB is a matter of the application protocol. For example, if you were doing XMPP over IBB, you would send all of your data followed by "</stream:stream>" but then not issue the iq to close the stream yet. The peer would then be able to respond with data. Now I hope *I* haven't missed something obvious. :) -Justin
