Subject: [BEEPwg] RFC3081/SEQ frame

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 24 Jul 2003 15:52:51 +0200

Hi list,

I am implementing a partial BEEP stack for rfc3195 syslog. 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,
--

I am doing testing against the RoadRunner library. I am sending syslog
raw (Rfc 3195) messages. My initiator sees SEQ frames from the listener
more or less at the end of the window, HOWEVER, the ackn points back to
frames that have already been sent some time before. I have confirmed
the timing with a network packet capture.

For example, I see an initial SEQ after sending 4070 bytes (which is
fine), but it specifies an ackno of 2839. If I look at the network
trace, frame 2839 has been packed by the IP stack into a single network
packet that goes up to seqno 2950. My app managed to send another two
packets (each one containing more than a single frame) before the SEQ
arrived.

Does this mean I need to retransmit everything beginning at 2839 (which
was a valid seqno)? I am right now *ignoring* the ackno at all and
continue sending as long as I receive a "good" SEQ back. In doing so,
all messages arrive without any one missing and in order. However, the
ackno diverts more and more from the actual seqno. For example, the last
SEQ has an ackno of 3453930 and I receive this frame after sending msg
3988850.

I would deeply appreciate if anybody could explain/provide pointers to
how this is supposed to work.

Many thanks,
Rainer Gerhards
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Marshall Rose <[email-masked]>
Date: Thu, 24 Jul 2003 09:11:55 -0700

> I am implementing a partial BEEP stack for rfc3195 syslog.
    
groovy!

> I have a
> ...
    
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