Subject: [BEEPwg] Question about terminating a session

From: "Randolph S. Kahle" <[email-masked]>
Date: 08 Mar 2002 14:27:42 -0700

I am working on an implementation of BEEP in Java
(http://www.simplebeep.org) and I am trying to figure out if I
understand the specification for the handshake at session termination
time.

The basic handshake is

<close code='200' />    -->
<ok />                  <--

<close connection>            <close connection>

However, with SEQ frames added (for the TCP/IP transport mapping), one
could have the following

<close code='200' />    -->
SEQ                     <--   (because it was fully read)
<ok />                  <--
SEQ                     -->   (same reason)

What about this last SEQ frame? How are other implementation handling
this final set of packets?

Is it a violation of the BEEP specification to send that frame or (as I
read it), not addressed.

Randy

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

---

From: Jered Floyd <[email-masked]>
Date: 08 Mar 2002 17:38:02 -0500

> this final set of packets?

PermaBEEP currently supresses any further traffic (including SEQ
traffic) on a channel (or session) after it has sent a close request
and before it has received a response.  In the case of a positive
response, no further traffic will be sent.  So, my implementation
will not send that final SEQ.

Note that this isn't entirely safe.  If your response to my close
request was larger than the channel window buffer free, we would
deadlock.  A similar concern exists with the implicit close of all
channels when TLS tuning. (See a thread on this I brought up a few
months ago.)

As a listener, PermaBEEP closes the session after acknowledging a
session close with a positive reply, so the SEQ is not a concern.

> Is it a violation of the BEEP specification to send that frame or (as I

This is an example of a subtle interaction between channel management
and transport mappings that I don't think is sufficiently explored in
the current spec.

--Jered

---

From: Darren New <[email-masked]>
Date: Fri, 08 Mar 2002 14:57:07 -0800

> will not send that final SEQ.

This needs to be done while starting security layers too. It's not
really new. An <start> that starts TLS with an embedded <ready> or a
<ready> on an already-open TLS channel has to do the same sort of thing.

> deadlock.

One method (used in beepcore-c) is to send the SEQ *before* the <close>
or <start> or whatever. At least you have the full window available.

> and transport mappings that I don't think is sufficiently explored in

Yes, it's a complex interaction there.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  To the user, everything works just as expected,
    assuming the user's expectations are correct.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg