[BEEPwg] Some SEQ frame questions

Peter Hall whiz100 at hotmail.com
Thu Jan 5 14:51:27 PST 2006

That's better, now I understand what it is trying to do. I never did it in
the first place because I could get my head around it.

I'll make the changes.


> From: David Blacka <davidb at verisignlabs.com>
> Date: Thu, 5 Jan 2006 14:16:39 -0500
> To: Peter Hall <whiz100 at hotmail.com>
> Cc: Francis Brosnan Blazquez <francis at aspl.es>, Paul Lacy
> <paul.lacy at hsd.com.au>, BEEPwg <beepwg at lists.beepcore.org>
> Subject: Re: [BEEPwg] Some SEQ frame questions
> 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