[BEEPwg] Some SEQ frame questions

Peter Hall whiz100 at hotmail.com
Thu Jan 5 12:45:57 PST 2006

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?

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.

Why send multiple SEQ messages if it's not changed? Isn't that just wasting

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.

The only reason I implemented what I did with the SEQ message with because
other vendors applications sent it.

Because I don¹t send a SEQ it just means I'll accept the default 4K.


> From: David Blacka <davidb at verisignlabs.com>
> Date: Thu, 5 Jan 2006 11:26:32 -0500
> To: Peter Hall <whiz100 at hotmail.com>
> Cc: Francis Brosnan Blazquez <francis at aspl.es>, Paul Lacy
> <paul.lacy at hsd.com.au>, BEEPwg <beepwg at lists.beepcore.org>
> Subject: Re: [BEEPwg] Some SEQ frame questions
> On Jan 5, 2006, at 9:03 AM, Peter Hall wrote:
>>> 3) It is easy to understand that any change required to the window
>>>  size for a given channel will required to produce a SEQ frame to be
>>>  sent, but if the window size doesn't change:
>>>  It is required to keep on sending SEQ frames notifying current
>>>  status of the channel buffer?
>> No need to keep sending them
> Um, no.  I think you've misunderstood how SEQ works.
> It is true that you do not have to send a new SEQ frame after every
> received frame (although you could).  You DO need to send one either
> before the original buffer size is exhausted, or immediately afterwards.
> What the SEQ frame says is: on this channel, you may send me N
> octets.  It isn't saying "break every message in to N octet frames".
>>> 4) What could happen if BEEP peer just ignore SEQ frames or don't
>>>  generate SEQ frames?
>> This is what I have done. I'll accept the SEQ frame but I never
>> send a SEQ
>> frame. When I send a message I'll split the message into whatever
>> the remote
>> peer SEQ requested.
> Have you actually interoperated with, say, beepcore-j?
> --
> David Blacka    <davidb at verisignlabs.com>
> Sr. Engineer    VeriSign Applied Research

More information about the BEEPwg mailing list