[Standards] Closing bidirectional IBB (XEP-0047)
stpeter at stpeter.im
Wed Feb 23 03:09:15 UTC 2011
[old thread alert!]
On 9/6/10 11:45 AM, Justin Karneges wrote:
> On Monday 06 September 2010 07:13:44 Sergei Golovan wrote:
>> 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
> Now I hope *I* haven't missed something obvious. :)
Well, if we were designing IBB again we'd probably do this:
(first party now stops sending data in the other direction, except it
can ack inbound data)
P2: [might send more data]
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
Example 8. Closing the bytestream
<iq from='romeo at montague.net/orchard'
to='juliet at capulet.com/balcony'
<close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/>
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
We can also add some text about this to XEP-0261.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards