Our client, SoapBox Communicator, makes extensive use of IBB.
We also went with an IQ based IBB mechanism that uses flow control.
We allow the sender to have a configurable number of IQ Packets to be
"in the network" (e.g. the sender hasn't yet gotten a response) at a
time, and when that limit is reached, no more data is sent until a
response is received.
This made it preferable to the message based bytestreams, which had some
major congestion issues around them, especially if the two endpoints
were on very asymmetric connections.
The IQ Packet we use inherits directly from an IQSetPacket, and looks
more-or-less like:
<iq type=set ...>
<data sequence='[Some Integer Value]'
streamid='stream this packet is for'>
Data Being Sent
</data>
</iq>
--
Chris Mullins
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Saint-Andre
Sent: Thursday, July 19, 2007 7:58 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards] XEP-0047 (Flow rate control for IBB)
William Voorsluys wrote:
> Hello,
>
>> > But, according to the XEP, it is not allowed to include any inner
XML
>> > stanza on the <iq> of type RESULT used as ACK:
>> >
>> > <iq from='[EMAIL PROTECTED]/balcony'
to='[EMAIL PROTECTED]/orchard'
>> > type='result' id='ibb1'/>
>>
>> That's just an example.
>> The RFC allows zero or one child element in IQ result stanzas.
>> This would work:
>>
>> <iq from='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard'
>> type='result' id='ibb1'>
>> <data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
>> </iq>
>
> Well, I don't think that XEP-0047 would allow such a response. It is
> not clear in the XEP that a client should reply including a <data>
> element preserving 'sid' and 'seq'. So, most clients wouldn't do that,
> preventing our implementation to interoperate.
> Am I right?
AFAIK, few clients have implemented IBB. We could definitely update the
spec to reflect this kind of acking, which makes a lot of sense IMHO.
Justin, what say you?
/psa
