[standards-jig] UPDATED: IBB (JEP-0047)
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
> 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">
> 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