Re: Some SEQ frame questions

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.

Thanks
Peter

> From: David Blacka <[email protected]>
> Date: Thu, 5 Jan 2006 14:16:39 -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 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    <[email protected]>
> Sr. Engineer    VeriSign Applied Research
> 
> 
> 
>