[BEEPbuilders] questions about session release and channel
Francis Brosnan Blazquez
francis at aspl.es
Mon Oct 23 17:08:32 PDT 2006
El dom, 22-10-2006 a las 21:33 +0200, Simon Raess escribió:
> I am currently implementing a BEEP library in Java for the
> collaborative text editor ACE (http://ace.sourceforge.net/). The
> library will (in its first version) be intentionally simple.
> Now, I
> have several questions about the BEEP specification.
> The first question concerns the session release. RFC 3080 is pretty
> specific about closing channels (section 126.96.36.199), but few
> are given for session shutdown (section 2.4). A BEEP library could
> disallow closing the session when there are still open channels.
> Then, releasing the session would be nothing else than closing
> channel 0 and then dropping the connection. This seems reasonable to
> me, but is that how it is meant to be? And how should a BEEP library
> behave when it receives a close for channel 0 when there are still
> other open channels? Should it send an error element in a negative
> reply, thus denying the close of the session? How do existing BEEP
> frameworks handle this situation?
You are right (or at least I think you do). A BEEP session cannot be
closed until all channels were closed (without including the channel 0
which is created and destroyed implicitly with the BEEP session).
Currently, Vortex Library denies closing the BEEP session if there are
channels running that weren't accepted to be closed. For us, closing the
session is the same as closing the channel 0.
> The second question is about closing channels. How should the
> following situation be handled? If both BEEP peers decide at about
> the same time to close a given channel, then it could happen that
> two close messages cross in transit. How should this situation be
> dealt with? Intersting effects could arise if one party accepts the
> request and the other declines the other request to close the session.
This isn't clear enough as you have found. Currently, Vortex Library
flags the channel as "being closed" just starting the close process.
Using this status, we handle the incoming close message for a close in
progress channel replying an error message ("channel is already in close
Obviously, this will make the session to not be closed. At this point,
the profile developed should take care about this situation going into a
However, knowing that BEEP requires a bit of provisioning, through a
profile, the implementor (in this is case not you, but the user of your
BEEP java library), will have to take a decision about how is handle
session closing in his profile, avoiding an scenario where both peers
could issue such request. I think, at the end, this is the best
> I'm interested to hear from builders of existing BEEP frameworks how
> the above two situations are handled and I'd really like to hear how
> this was intended from the author(s) of RFC 3080.
Let us to know your progress Simon!
> Simon Raess
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.
More information about the BEEPbuilders