Re: RFC3081/SEQ frame

> I am implementing a partial BEEP stack for rfc3195 syslog.
    
groovy!
    
    
> I have a
> question in regard to the SEQ message. RFC3081 says regarding ackn
> 
> --
>  o  an acknowledgement number, that indicates the value of the next
>       sequence number that the sender is expecting to receive on this
>       channel; and,
> --
> ...
    
two things:
    
1. you never re-transmit anything. tcp is giving you reliability. the
   SEQ frame is allowing you to share bandwidth between multiple
   channels being multiplexed on the same tcp connection.
    
2. the SEQ frame isn't supposed to be synchronized with what you're
   sending (unless the window goes to zero). what you do is keep track
   of the number of octets you've sent. the SEQ frame tells you how many
   more octets you're allowed to send.
    
so, if you see
    
       SEQ 1 100 2000
    
the way to interpret this is the remote peer saying
    
    at the time that i had received 100 octets from you on channel 1, i
    was prepared to accept up to another 2000 octets from you.
    
let's say you've gotten this after sending a total of 1900 octets on
channel 1. by my math, you can now send upto 200 octets on channel 1.
    
presumably, as the remote peer is receiving data from you, it's passing
that up to the application, and sending back another SEQ.
    
in fact, you may see a SEQ even if you haven't sent traffic for a while,
simply because the application has consumed previous traffic you've sent
and the window is opened up...
    
/mtr