Re: Some SEQ frame questions

I've just had confirmation that a vender has used beepcore-java and it works
fine with my implemention.

P

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