[BEEPbuilders] questions about session release and channel close

[David Kramer]

Hi Simon,

> The first question concerns the session release. RFC 3080 is pretty  
> specific about closing channels (section 2.3.1.3), 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  
2.3.1.3 specifically excludes channel 0 from the remainder of that  
section.

>   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.

> 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  
> session.

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 2.3.1.3  
specifically excludes channel 0 from the rules.

> 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.
>
> Thanks!
> Simon Raess
>
> _______________________________________________
> BEEPbuilders mailing list
> BEEPbuilders at lists.beepcore.org
> http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepbuilders