Re: Some SEQ frame questions

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

Well, or SEQ frames are windows rolling on mech reporting to the remote
peer how many data could hold at a particular time until get it into the
application level or it is something else!. In case that SEQ frames are
buffer size ack mechanism, ackno value should play a very important role
on this issue.

>From your next two comments, could you be more specific?:

1)---
> 2) Because the purpose of the SEQ frame, it is stated that they should
>    have greater priority over same messages on the same channel, but,
>    this will break the principle "every message send on the same
>    channel is sent sequentially".

What is being said is that the SEQ frames should be given priority in  
the sequence.
1)---

2)---
>    Does this means that over the same channel "normal" frames are sent
>    sequentially but, there another queue with higher priority to send
>    SEQ frames generated?

That is one way to implement it, but not the only way.
2)---

Great reply David, 

-- 
Francis Brosnan Blazquez <[email protected]>
Advanced Software Production Line, S.L.