Re: Some SEQ frame questions

> The way I read it was that the SEQ message says don't send me  
> frames larger
> X. is that wrong?

Yes, that is incorrect.

I think I can make this clearer for everyone with an example.

When a channel opens, the receiving window size for both peer A and  
peer B is 4096 bytes.  If peer A sends a frame with a payload of size  
1024 to peer B, then peer B's receiving window size shrinks to 3072.   
If peer A sends another frame with payload size 1024 to peer B, then  
peer B's receiving window size shrinks further to 2048.  If peer B  
never sends a SEQ frame, and peer A continues to send frames, then  
peer B's receiving window size will eventually reach zero.  At this  
point, if peer A sends any data to peer B, this is a protocol  
violation and peer B immediately terminates the session.

What you need to understand is that the window shrinks with every  
byte received.  The SEQ doesn't say "this is the maximum per-frame  
size I'll accept whenever", it says "this is the total number of  
bytes you may send me until I send you a new SEQ frame extending the  
window."  For a window size of 4096 it could by 4096 1-byte frames,  
or 1 4096-byte frame, or some combination in between.

Note that it is required for a BEEP stack to deal with SEQ frames in  
the middle of a message.  For instance, if peer A wants to sends a  
message that is 5000 bytes long, and peer B has a receiving window  
size of of 4096, then peer A could send a frame no larger than 4096  
bytes.  At this point, peer A still has 4 bytes left to send, which  
it cannot do until it receives a new SEQ frame from peer B extending  
with window by at least 4 bytes.  Therefore peer B needs to be able  
to send SEQ frames in the middle of receiving the message, and peer A  
needs to be able to receive SEQ frames in the middle of sending the  
message.

This might be easier to understand if you consider what the reasoning  
behind the SEQ frame is.  It is a mechanism for flow control.  It is  
a way for peer B to say, I have only allocated a certain amount of  
memory for receiving frames, so don't send me more than that until I  
say it's okay.  If peer B wants to receive a message larger than the  
window size, then peer B will have to send SEQ frame, which it will  
do once it has allocated additional space to receive it.

Suppose peer A wants to send a large file to peer B, which peer B  
will save to disk.  However, peer B doesn't have very much memory  
available.  Therefore, peer B will advertise a small (4K) window, and  
every time the window gets close to being filled, it will write out  
all of the data from memory onto disk, and then grow the window back  
to 4K.  This way peer B never requires more than a 4K buffer for  
holding frame payloads but it can still receive a very large file.

Another tricky aspect of SEQ handling is that each channel of each  
peer has it's own independent receiving window size.  Thus there are  
two window sizes associated with each channel.  Each peer needs to  
know the size of the window being advertised by the other, while at  
the same time keeping track of the window it has advertised to the  
other.  The former is important so that the peer doesn't send more  
data than the other can handle, while the latter is important so that  
the peer knows when it needs to send a SEQ to the other to re-extend  
the window.

Another point which was made earlier is that the window may never be  
shrunk by a SEQ frame.  The window is only, and always, shrunk as the  
result of receiving data.  The sending peer needs to keep track of  
how many bytes it sends and subtract that from the last advertised  
window size, so that it never sends more data than can fit in the  
window.  Likewise, the receiving peer needs to keep track of how many  
bytes it receives and subtract that from the last window size it  
advertised, so that it knows when the window is full and needs to be  
re-extended.

-David Kramer

On Jan 5, 2006, at 9:45 AM, Peter Hall wrote:

>
> I'm not sure if I've tried against beepcore. I'm trying to findout  
> for sure
> I've personally not done it.
>
> The way I read it was that the SEQ message says don't send me  
> frames larger
> X. is that wrong?
>
> What I think your saying is don’t send a message with a total  
> payload larger
> that X. in other words send me either 1 message no larger than X or  
> send me
> many continuation messages but not to exceed X.
>
> Why send multiple SEQ messages if it's not changed? Isn't that just  
> wasting
> bandwidth?
>
> As it happens my application a reliable syslog server/client don't  
> need to
> send more than 4K so may be I've just not had to deal with that  
> problem.
> saying that it does work against over vendors servers/clients.
>
> The only reason I implemented what I did with the SEQ message with  
> because
> other vendors applications sent it.
>
> Because I don’t send a SEQ it just means I'll accept the default 4K.
>
> Peter
>
>
>> From: David Blacka <[email protected]>
>> Date: Thu, 5 Jan 2006 11:26:32 -0500
>> To: Peter Hall <[email protected]>
>> Cc: Francis Brosnan Blazquez <[email protected]>, Paul Lacy
>> <[email protected]>, BEEPwg <[email protected]>
>> Subject: Re: [BEEPwg] Some SEQ frame questions
>>
>>
>> On Jan 5, 2006, at 9:03 AM, Peter Hall wrote:
>>
>>>> 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
>>
>> Um, no.  I think you've misunderstood how SEQ works.
>>
>> It is true that you do not have to send a new SEQ frame after every
>> received frame (although you could).  You DO need to send one either
>> before the original buffer size is exhausted, or immediately  
>> afterwards.
>>
>> What the SEQ frame says is: on this channel, you may send me N
>> octets.  It isn't saying "break every message in to N octet frames".
>>
>>
>>>>
>>>> 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.
>>
>> Have you actually interoperated with, say, beepcore-j?
>>
>> --
>> David Blacka    <[email protected]>
>> Sr. Engineer    VeriSign Applied Research
>>
>>
>>
>>
>
>
> _______________________________________________
> BEEPwg mailing list
> [email protected]
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg