[Standards] Closing bidirectional IBB (XEP-0047)

Peter Saint-Andre 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:
>> 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='romeo at montague.net/orchard'
    id='us71g45j'
    to='juliet at capulet.com/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/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110222/773c9d13/attachment.bin>


More information about the Standards mailing list