[BEEPwg] Some SEQ frame questions
mrose at dbc.mtview.ca.us
Thu Jan 5 10:58:46 PST 2006
> 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
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.
More information about the BEEPwg