Re: Some SEQ frame questions

Francis

See my comments inline

> From: Francis Brosnan Blazquez <[email protected]>
> Organization: Advanced Software Production Line, S.L.
> Date: Thu, 05 Jan 2006 10:04:06 +0100
> To: Paul Lacy <[email protected]>, BEEPwg <[email protected]>
> Subject: [BEEPwg] Some SEQ frame questions
> 
> 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:
> 
> 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 4.2.2.16 of RFC1122 [5] 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
>  received?

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!
> 
> Cheers! 
> 
> [1] http://dolphin.aspl.es/cgi-bin/bugzilla/show_bug.cgi?id=277
> 
> 
> -- 
> Francis Brosnan Blazquez <[email protected]>
> Advanced Software Production Line, S.L.
> 
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg
>