Subject: [BEEPwg] SEQs after channel close request?

From: Jered Floyd <[email-masked]>
Date: 30 Jun 2003 10:43:04 -0400

Here we go again. :-)

This is similar to a complaint I had last year regarding
synchronization for TLS negotation, where I was shouted down for
constructing overly obscure scenarios.  This is less obscure, and
actually a problem I'm running into, but I'm not sure how to best fix.

While adding some functionality to PermaBEEP, we encountered a bug we
hadn't noticed before.  PermaBEEP will not send SEQ frames for a
channel once it has processed a locally-initiated request to close for
that channel.

It doesn't want to generate any further outbound traffic on the
channel after the close request, because as soon as the remote side
accepts, the remote side considers the channel to be closed.  Once
the remote peer has processed the close, if it saw a SEQ for the
channel in response to it's 'ok' response, it would terminate the
connection as per RFC 3081, 3.1.3:

   When a SEQ frame is received, if any of the channel number,
   acknowledgement number, or window size cannot be determined or is
   invalid, then the BEEP session is terminated without generating a
   response, and it is recommended that a diagnostic entry be logged.

(The channel would be closed and thus invalid.)

So, the local peer isn't going to be sending any new MSGs after it's
made a close request, however RFC 3080, 2.3.1.3:

   NOTE WELL: until a positive reply to the request to close the channel
   is received, the BEEP peer must be prepared to process any "MSG"
   messages that it receives on that channel.

This means that once the local peer has sent a close, it must be
prepared to process and respond to additional MSGs from the remote
peer, and respond to them (with RPY, ANS, or ERR frames).

Sending these frames isn't a problem because the remote peer isn't
going to accept the close until after it's received complete replies
to its outstanding MSGs, so those RPY, ANS, and ERR frames won't ever
be received on a channel that the remote peer believes is closed.

HOWEVER, because the local peer must still be prepared to handle
incoming MSGs after it has sent a close request, the local peer MUST
continue sending SEQs or else the channel will stall as the incoming
MSG data is not acknowledged.  But, the local client has know way of
knowing when the remote peer is done sending MSGs and has processed
and accepted the close request, so may send a SEQ after the remote
peer believes the channel is closed.

Any ideas how to resolve this?  Two thoughts I've had:
  - Do not consider SEQ frames for a recently closed channel to be
    an error. (This requires some definition of 'recently closed'.)

  - On the local peer, after sending a close request, the last frame
    sent on a channel must not be a SEQ frame.  If we are receiving
    incoming MSGs then we can happily send SEQs until we have sent the
    final frame of the response for all known incoming MSGs.

I think the latter item there will work but, well, it seems overly
complicated.  What have other implementors done?

--Jered

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Darren New <[email-masked]>
Date: Mon, 30 Jun 2003 09:30:10 -0700

> complicated.  What have other implementors done?

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.

The other problem you run into is when a response to a close carries 
more data than your window can accept. This is more of a doctor-doctor 
problem. ("Doctor, Doctor, it hurts when I do this!"  "Then don't do that.")

Hope this helps.

-- 
Darren New, San Diego CA USA (PST)
Things to be thankful for, #187:
  There is no Chinese tradition of changing from
  shoes to slippers to get off an escalator.

---

From: Marshall Rose <[email-masked]>
Date: Mon, 30 Jun 2003 09:51:35 -0700

> for your response and therefore hasn't processed the close yet.

this is the same approach i used in beepcore-tcl: SEQs go first.
    
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.
    
/mtr

---

From: Jered Floyd <[email-masked]>
Date: 30 Jun 2003 13:09:07 -0400

Thanks; I ended up implementing something like this just now.  If
there exist any messages that have not yet been fully replied to,
I will send SEQs, otherwise not.

--Jered

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jun 2003 11:32:31 -0700

On Monday, Jun 30, 2003, at 09:51 US/Pacific, Marshall Rose wrote:
> [ Darren New wrote:]

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.

> to ignore SEQs on unknown channels.  it's hard to see any downside in

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-masked]>
that's my village calling... no doubt, they want their idiot back.