[BEEPbuilders] questions about session release and channel close

[Simon Raess]

Hi David

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

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

Thanks for the enlightenment. :)

Simon