[BEEPwg] Some SEQ frame questions
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  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
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
> 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?
> 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
> 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*
David Blacka <davidb at verisignlabs.com>
Sr. Engineer VeriSign Applied Research
More information about the BEEPwg