Re: SEQs after channel close request?

On Monday, Jun 30, 2003, at 09:51 US/Pacific, Marshall Rose wrote:
> [ Darren New wrote:]
>> While doing Beepcore-C's core, I noticed this problem. I only send 
>> SEQs
>> *before* sending outgoing packets. That is, I send the SEQ just before
>> sending the RSP or ANS, so it really isn't a problem. As long as the 
>> SEQ
>> isn't the last packet you send, the other side should always be 
>> waiting
>> for your response and therefore hasn't processed the close yet.
>
> this is the same approach i used in beepcore-tcl: SEQs go first.

There is a further complication.  You can't wait until just before 
sending a reply before emitting the SEQ frame.  My implementation will 
send the SEQ frame immediately after extending the window-- which 
happens when the MSG is acknowledged by the application layer, and 
possibly well before the application sends a reply.

After the local peer sends a <close> request and before it receives the 
<ok> reply, if it receives a MSG for which the application at the local 
peer does not have any response other than to extend the channel window 
(to receive more pipelined requests) then the local peer must send a 
SEQ immediately, while a RPY, ERR or ANS (or the transport reset event) 
may not be forthcoming until after the application receives more MSG 
requests.

> when the spec gets updated, i don't have a problem in changing the spec
> to ignore SEQs on unknown channels.  it's hard to see any downside in
> that.

I don't see any problem with that, but I don't think it is necessary.

Implementations can be compliant with the proposed standard without 
ever sending a SEQ frame on a channel that has been closed already.

Don't send the <ok> in reply to a <close> request until: 1) you have 
received all the replies for any messages sent; and 2) you have no more 
messages to send.


-- 
j h woodyatt <[email protected]>
that's my village calling... no doubt, they want their idiot back.