Re: Some SEQ frame questions

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
bandwidth?

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.

Peter


> From: David Blacka <[email protected]>
> Date: Thu, 5 Jan 2006 11:26:32 -0500
> To: Peter Hall <[email protected]>
> Cc: Francis Brosnan Blazquez <[email protected]>, Paul Lacy
> <[email protected]>, BEEPwg <[email protected]>
> 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    <[email protected]>
> Sr. Engineer    VeriSign Applied Research
> 
> 
> 
>