[BEEPwg] Some SEQ frame questions
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
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
> 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
> 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