[BEEPwg] Some SEQ frame questions
Francis Brosnan Blazquez
francis at aspl.es
Thu Jan 5 10:04:06 PST 2006
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
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.
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?
But, what if the remote side doesn't agree on changing requested
value for the new window size?
How it is used the ackno value for the SEQ frame received?
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".
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?
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?
Any comment would be appreciated!
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.
More information about the BEEPwg