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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Mar 25 18:17:23 UTC 2003


Justin Karneges <justin-jdev at affinix.com> wrote on 25-3-2003 4:03:39:
>
>Hi Tijl,
>
>On Monday 24 March 2003 05:07 pm, Tijl Houtbeckers wrote:
>> Why a 16bit integer maximum? (why not 32bit wich would be practically
>> infinite?)
>
>We (temas, matthew miller, and I) discussed the issue of sequencing 
>packets recently.  There was a divide in our way of thinking:  I 
>wanted an incrementing counter, while matthew suggested the use of an 
>accurate timestamp.

I'm all for an incremental counter. I don't think there any systems 
still out there that have difficulties processing 32bit integers though 
(you don't have to run on a 32-bit architecture for that.) But 16-bit 
is fine too I suppose. 

> [...]

>> Is the value of newseq always "0" or must it be incremented
>> each time a new sequence ends?
>
>In my vision, you'd always set it to zero, to indicate that you are 
>starting over.  But then if you're always setting it to zero, the 
>value is pretty useless.  May as well just say newseq="true".

newseq="true" would indeed prevent that kind of confusion.
In theory there is no garantueed order of delivery. I could generate 
2*65535 packets and recive the last packet first. I have no way of 
knowing wich sequence it would be belong to, except... 

>
>Perhaps a better idea would be to have a lastseq attribute:
>
><iq type="set" id="inband_1" to="joe at blow.com/Home">
>  <query xmlns="http://jabber.org/protocol/ibb" sid="mySID" seq="0" 
>lastseq="65535">
>    <data>blahblahblah</data>
>  </query>
></iq>
>
>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). 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. 

>> A mechanism to allow other things as Base64?
>
>I say no.  To maximize compatibility, we should enforce one encoding.

Compatability is nice, but at what price? 
In any case I do propose support for Base64 would be mandatory (clients 
MUST support Base64). Base64 is actually pretty good on UTF-8, but 
horrible inefficient on UTF-16 (why use 6 bits when you can use at 
least 15? using 8 or 12 would be much more efficient in any case). 
Because I can see a possible need for this, I wonder why there should 
be a seperate JEP that is almost exactly the same except for the name 
of the namespace and the encoding. My "choice-is-good" aditute on this 
subject has come up before I guess.. 

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? 

-- 
Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list