Re: Some SEQ frame questions

> This might be easier to understand if you consider what the  
> reasoning behind the SEQ frame is.  It is a mechanism for flow  
> control.  It is a way for peer B to say, I have only allocated a  
> certain amount of memory for receiving frames, so don't send me  
> more than that until I say it's okay.  If peer B wants to receive a  
> message larger than the window size, then peer B will have to send  
> SEQ frame, which it will do once it has allocated additional space  
> to receive it.

i agree with absolutely everything in your email as to how SEQ works  
and why; however, i want to add one thing to the above paragraph:  
let's answer the question: "why?".

after any tuning, if you could open only one channel for data  
exchange, then you wouldn't have SEQ frames in BEEP. they wouldn't be  
needed.

however, because you are allowed to open multiple simultaneous  
channels for data exchange, you can run into a problem commonly  
referred to as "head of line". this is where one channel monopolizes  
all of the underlying transport capacity by sending something really  
big, and the other channels get blocked behind that data.

so, what SEQ allows a BEEP peer to do is coordinate use of the  
available bandwidth by the channels being multiplexed over a single  
TCP connection. for example, the BEEP API you use may allow you to  
associate a priority with each channel (or each message sent by a  
channel), then when the implementation of that API sees that it's  
able to send a frame over the TCP connection, it can determine which  
channel should get to use the bandwidth.

/mtr