[standards-jig] UPDATED: IBB (JEP-0047)

Justin Karneges justin-jdev at affinix.com
Tue Mar 25 23:08:04 UTC 2003

> >Normally, an IBB implementation should queue packets in order to
> >ensure proper sequence.  Each packet essentially as a dependency: the
> >packet before it.  When the maximum counter is reached, lastseq could
> >be used to indicate a different dependency, as opposed to seq-1 (the
> >default).
> If you propose the lastseq="65535" is send along with every packet in
> the new sequence (and lastseq="131070" for the sequence after that, but
> then we overflow the 16-bit int again).

Actually my thought was that you'd always use lastseq="65535", again with 
almost the same redundancy as newseq="0".  If you happened to get the 65536th 
packet before the 1st, then your connection is essentially toast.

> Another idea could be
> generating a new sid for every sequence:
> <iq type="set" id="inband_1" to="joe at blow.com/Home">
>   <query xmlns="http://jabber.org/protocol/ibb" sid="mySID1"
>   seq="65535" nextsid="mySID2">
>     <data>blahblahblah</data>
>   </query>
> </iq>
> If you happen to receive any packets out of order with a sid you don't
> know yet you could keep them for a while.

I'm not sure this really solves the problem.  May as well bump the main 
counter to 32bit.

> Also, in the examples I don't see any IQ type="result" packets send out
> any longer when a data-packet is received (I believe there used to be
> in your last proposal for IBB). Is this done on purpose? (bandwidth
> concerns?) Or should we still send them? (in wich case it should be in
> the example to be clear). If we wouldn't send them, isn't that a bit
> against the nature of IQ?

According to temas, removing the 'acks' would speed up the data exchange.  
This is why a sequence number was added.  If we were acking everything, then 
we wouldn't need such a counter.

I propose switching the counter size to 32bit, and changing newseq to lastseq.  
What do you think?


More information about the Standards mailing list