[BEEPbuilders] questions about session release and channel close
cocoa at gmx.ch
Mon Oct 23 22:22:53 PDT 2006
On 23.10.2006, at 20:07, David Kramer wrote:
> Hi Simon,
>> The first question concerns the session release. RFC 3080 is
>> pretty specific about closing channels (section 184.108.40.206), but few
>> guidelines are given for session shutdown (section 2.4).
> Closing a session is the same as closing channel 0. And although
> it is tempting to treat channel 0 like any other channel, section
> 220.127.116.11 specifically excludes channel 0 from the remainder of that
I've missed that remark, but combined with your remark about the
possibility of a deadlock, it makes sense.
>> 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?
> I believe this must be a policy decision made by the application
> adopting the framework. The framework should provide a mechanism,
> either via a configuration setting, or a callback, for the
> application to decide how to respond to a session-close request.
> One policy the framework could implement is that a received session-
> close request is only accepted if the receiver is legally allowed
> to close all currently open channels. In other words, a peer
> should reject a session-close request if it has any open non-zero
> channels for which it has sent unanswered MSGs.
This sounds reasonable. Definitely less constraining than my proposal.
>> 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
>> the 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
> If you have sent a close-session request and you receive a close-
> session request, there is only one reasonable thing to do -- reply
> "ok". Any peer that rejects a close-session request it receives
> while it has an outstanding sent close-session is at best behaving
> pathologically. Note that as soon as you reply "ok" you are
> supposed to close the TCP connection (assuming TCP) -- you are not
> allowed to wait for the reply to your own request in that case.
> Basically, when you send a session-close request, you have a
> contract with your peer that you will close the connection the
> moment you receive an "ok" reply, and you must assume that if you
> receive an "ok" reply that the other peer has already closed the
> connection. Conversely, if you receive a session-close request
> while waiting for a reply to your own session-close request, then
> the remote peer is expecting that you'll close the connection as
> soon as you reply "ok", so it has no reasonable expectation that
> you would be listening even if it did try to reject your session-
> close request.
> Now, if channel 0 were treated like all other channels, then the
> only correct behavior would be to reject the session-close
> request. This is because for a regular channel you can not legally
> reply "ok" to a close request until you're received full replies
> for all of your MSGs. But both peers will be waiting for the
> other's reply before sending their own -- deadlock. I believe this
> is why section 18.104.22.168 specifically excludes channel 0 from the rules.
Thanks for the enlightenment. :)
More information about the BEEPbuilders