[standards-jig] IBB: Making it all "go"

Justin Karneges justin-jdev at affinix.com
Fri Apr 11 02:51:33 UTC 2003


On Thursday 10 April 2003 12:21 pm, Peter Millard wrote:
> ack every packet? It seems more than sufficient in almost all cases to say
> ack every 5th packet. This is especially true if we've negotiated a packet
> size and or "# of packets per ack" parameters. (Which would be a nice

But then what is the difference between acking every 5th packet vs generating 
gigantic packets and acking each one?  Basically, it comes down to how many 
bytes to send before we ack.  We've already established that acking is a 
requirement, so just tell me the number of bytes-per-ack and we can use <iq>. 
;-)

> We're not complicating things, we're trying to do it the _right_ way. Why
> rush things?? We've made enough mistakes with protocol in the past, the

Part of IBB's goal is to remain compatible with all existing and future server 
implementations.  Are we throwing that out the window?

I think when you weigh the options, compatibility with existing servers is 
more important than waiting for fixed <message> specs and implementations.  
Either way, IBB would solve the job.  The reason to wait would be if using 
<iq> for data delivery is somehow "wrong", but there is no such thing.  <iq> 
is the correct choice for anything that requires an ack, the content is 
irrelevant.

On Thursday 10 April 2003 07:24 pm, Rachel Blackman wrote:
> then I should be able to.  If I want to ack every tenth packet, I should be
> able to.  If I don't want to ack anything for whatever reason, I should
> still be able to.

IBB = Inband Bytestream, hopefully implying reliability, but I can add the 
word in there if needed.  This means acking is mandatory.  If you want UDP, 
just use <message>. ;-)

I think maybe there is some confusion about everyone having different goals 
for IBB.  I think the Council members in this discussion need to read the 
introductory parts of JEP-0047, and mention how their goals conflict.

-Justin



More information about the Standards mailing list