[BEEPwg] Some SEQ frame questions

David Blacka davidb at verisignlabs.com
Thu Jan 5 14:16:39 PST 2006

On Jan 5, 2006, at 12:45 PM, 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?

SEQ is advertising a current buffer size for a channel for that  
moment in time (or more precisely, for a particular sequence  
number).  It isn't talking about frames specifically.

> 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.

It is saying that you can send up to X octets without another SEQ,  
regardless of the message/frame breakdown.

> Why send multiple SEQ messages if it's not changed? Isn't that just  
> wasting
> bandwidth?

SEQ is implementing flow control, so think of it as an ACK.

> 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.

Well, you would be able to send *only* 4k on a given channel.  Well,  
reliably in any case.  Also keep in mind that you will be able to  
perfectly interoperate with yourself.  So if both peers are using  
your BEEP implementation, I wouldn't expect a problem.

> The only reason I implemented what I did with the SEQ message with  
> because
> other vendors applications sent it.

Well, they have to.

> Because I don’t send a SEQ it just means I'll accept the default 4K.

It means you will only accept 4k total on each channel.

Here is what BEEP implementations need to do with respect to SEQ:

Senders must track on a per channel basis how many octets they are  
allowed to send.  So, initially, on channel creation, this may be set  
to 4096.  Now lets say you send 200 octets in two frames.   
Immediately, the sender updates this number to 3896, and notes that  
it has sent a total of 200 octets.  Now lets say that the sender has  
received a SEQ frame that says "SEQ 1 100 4096".  This means: "after  
receiving octet 100 on channel 1, I can receive 4096 more octets of  
payload".  So the sender gets to update its number to 3996.  It is  
now allowed to send at most 3996 octets before getting another SEQ  
frame.  Note that the ackno field is critical here.

Receivers need to have a mechanism for knowing when they must send a  
SEQ frame to prevent the channel from stalling.  In general, they do  
this by mirroring the calculation that the sender is doing (i.e.,  
subtract on receipt of data, resetting when sending a SEQ), but this  
isn't the only way to do it.

Also note that like sequence numbers, SEQ frames operate on a per- 
channel and per-direction basis.

David Blacka    <davidb at verisignlabs.com>
Sr. Engineer    VeriSign Applied Research

More information about the BEEPwg mailing list