[BEEPbuilders] questions about session release and channel close

Simon Raess cocoa at gmx.ch
Tue Oct 24 00:18:21 PDT 2006

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

You only answered how close requests for channel 0 that cross in  
transit should be handled. What about close requests of any other  
channel? It makes sense (too me) to reply to those close requests  
with an ok message too. After all, the peer requested to close the  
session so it wouldn't be sane to reply with an error in that case. I  
think it should then still wait for the response to it's own close  
request and be prepared to handle a negative response. Or?

Too bad that this part of RFC3080 is underspecified. After all,  
what's the use of a standard if there is room for such  
interoperability problems between implementations?


More information about the BEEPbuilders mailing list