[BEEPwg] Some SEQ frame questions
whiz100 at hotmail.com
Thu Jan 5 09:03:51 PST 2006
See my comments inline
> From: Francis Brosnan Blazquez <francis at aspl.es>
> Organization: Advanced Software Production Line, S.L.
> Date: Thu, 05 Jan 2006 10:04:06 +0100
> To: Paul Lacy <paul.lacy at hsd.com.au>, BEEPwg <beepwg at lists.beepcore.org>
> Subject: [BEEPwg] Some SEQ frame questions
> 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
> 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.
Correct. But RFC3081 has an implementation guideline that says "For
example, Section 220.127.116.11 of RFC1122  indicates that a "receiver
SHOULD NOT shrink the window, "
> 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?
I cannot find an answer to this one. Read the 3 bullet points in rfc3081
3.1.2 Sending Messages
1) segment messages
2) delay until the window is large enough
3) report error to application
> How it is used the ackno value for the SEQ frame received?
There is nothing.
> 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
No changes to the counts
> 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?
No need to keep sending them
> 4) What could happen if BEEP peer just ignore SEQ frames or don't
> generate SEQ frames?
This is what I have done. I'll accept the SEQ frame but I never send a SEQ
frame. When I send a message I'll split the message into whatever the remote
peer SEQ requested.
When I receive a segmented message I'll cache the data until I received the
final piece. Only after I've received the complete message do I hand it back
to the application.
> Any comment would be appreciated!
>  http://dolphin.aspl.es/cgi-bin/bugzilla/show_bug.cgi?id=277
> Francis Brosnan Blazquez <francis at aspl.es>
> Advanced Software Production Line, S.L.
> BEEPwg mailing list
> BEEPwg at lists.beepcore.org
More information about the BEEPwg