[old thread alert!] On 9/6/10 11:45 AM, Justin Karneges wrote: > 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. :)
Well, if we were designing IBB again we'd probably do this: P1: </close> (first party now stops sending data in the other direction, except it can ack inbound data) P2: [might send more data] P2: </close> But we don't have that, so we can either define it or add some clarifying text, such as: ### 2.3 Closing the Bytestream To close the bytestream, either party sends an IQ-set containing a <close/> element. Example 8. Closing the bytestream <iq from='[email protected]/orchard' id='us71g45j' to='[email protected]/balcony' type='set'> <close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/> </iq> The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original <close/> element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed). ### We can also add some text about this to XEP-0261. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
