[BEEPwg] Some SEQ frame questions

David Blacka davidb at verisignlabs.com
Thu Jan 5 11:07:39 PST 2006

On Jan 5, 2006, at 4:04 AM, Francis Brosnan Blazquez wrote:

> Hi there,
> Now some technical question about BEEP and SEQ frames:
> Paul [1] have reported a bug on the Vortex Library bugzilla showing
> that SEQ frame are still not really supported. While making some code
> to finish this area in a basic manner I've runned into the following
> questions:

One thing that may not be clear here: supporting SEQ frames is  
REQUIRED if you want your BEEP implementation to interoperate with  
other BEEP implementations.  There is some flexibility in how the  
implementation actually handles them, but it must honor incoming SEQ  
frames and emit SEQ frames.

I have, in the past, worked with a BEEP implementation that didn't  
support SEQ frames, and it did work fairly well with itself (this was  
beepy, prior to its switch to using twisted), but it had no hope of  
working with any other BEEP implementation.

> 1) If a client peer wants to reduce/increase the window size for a
>    given channel, one might deduce that it should issue a SEQ message
>    with the desired new window size.

Um, yes, but I'm not sure you are seeing what the SEQ frame is  
saying.  It isn't saying that "oh, I accept messages up to 4k", it is  
saying "I have 4k available *right now*".  That is, the SEQ frame  
isn't a policy announcement, it is a statement about what the peer is  
willing to accept at that moment.

>    This will produce that the local window size will be configured
>    with the new window size and a SEQ frame is set to the remote
>    peer. It this right?

I couldn't parse this question.

>    But, what if the remote side doesn't agree on changing requested
>    value for the new window size?

There is no room for disagreement.  It is up to the remote side to  
not send more data than the local side is willing to accept.

>    How it is used the ackno value for the SEQ frame received?

I can't remember anything specific.  In general, it is probably used  
as a sanity check.

> 2) Because the purpose of the SEQ frame, it is stated that they should
>    have greater priority over same messages on the same channel, but,
>    this will break the principle "every message send on the same
>    channel is sent sequentially".

What is being said is that the SEQ frames should be given priority in  
the sequence.

>    If there are 10 frames waiting to be send and a SEQ frame is issued
>    then these messages are freezed until the SEQ frame is sent?

Could be.

>    Does this means that over the same channel "normal" frames are sent
>    sequentially but, there another queue with higher priority to send
>    SEQ frames generated?

That is one way to implement it, but not the only way.

>    Does SEQ frames increase frame octec counting (seqno, size) or the
>    message counting (msgno) for a channel when the are sent and
>    received?

> 3) It is easy to understand that any change required to the window
>    size for a given channel will required to produce a SEQ frame to be
>    sent, but if the window size doesn't change:
>    It is required to keep on sending SEQ frames notifying current
>    status of the channel buffer?


> 4) What could happen if BEEP peer just ignore SEQ frames or don't
>    generate SEQ frames?

When I was implementing my own BEEP implementation (the  
Net::BEEP::Lite perl module), I found SEQ to be the hardest thing to  
grasp, so I'm not particularly surprised when implementations skip  
it.  However, SEQ is not an optional part of BEEP over TCP.

What SEQ is doing, essentially, is saying: "hey! I can receive N  
octets on this channel!".  If you are a sender, it is required that  
you do not send any more than N octets on that channel, possibly  
causing the message to fragment. (note that the octet count doesn't  
include the frame header and \r\nEND bit).  If you, as the sender,  
actually send more than N octets, then you can expect the remote end  
to either discard data or to freak out and end the session.  So, this  
is why ignoring incoming SEQs isn't a good idea.  If you are  
receiving data, yet not emitting SEQs, then the remote sender will  
stop sending you data past the default SEQ of 4096 octets.   
Essentially, your channel will quickly stall.  So this is why it is a  
good idea to *send* SEQs.

Now, as I stated at the top of this message, if both sender and  
receiver are ignoring SEQs, then the protocol will work, which is why  
an implementation can get away with not implementing SEQ support:  
they self-interoperate.  However, the implementation will NOT  
interoperate with a different BEEP implementation that *does*  
implement SEQ.

David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    VeriSign Applied Research

More information about the BEEPwg mailing list