Re: Some SEQ frame questions

On Jan 5, 2006, at 1:45 PM, Francis Brosnan Blazquez wrote:

> El jue, 05-01-2006 a las 11:07 -0500, David Blacka escribió:
>
> Hi David, really helpful comments!,
>
> As you have clearly described, it seems that the SEQ frames is a  
> kind of
> ACK datagram commonly used on many underlaying protocols that allow
> peers to perform flow control, so:
>
> 1) It is up to each peer to announce the SEQ frame for its own channel
> window (maybe should be called "buffer") sizes and ...
>
> 2) Remote peer receiving SEQ frames MUST follow that information to
> avoid getting annoyed (aka flooded) its partner peer.
>
> But, what makes me get confused is that RFC3081 doesn't say something
> like: "BEEP peers receiving a SEQ frame should take its ackno value to
> check it with current seqno over the selected channel and limit its  
> next
> sending to the window value received, including stopping from sending
> more data if it is overflow, until a next SEQ frame is received".
>
> Then I read your comment:
>
> ---
>>    How it is used the ackno value for the SEQ frame received?
>
> I can't remember anything specific.  In general, it is probably used
> as a sanity check.
> ---

Yeah, I spaced for a moment.  The ackno value is, indeed, critical.   
In my head I was thinking that that field was called "seqno" and  
ackno was some other useless field.  This is what you get from not  
looking stuff up!

--
David Blacka    <[email protected]>
Sr. Engineer    VeriSign Applied Research