[BEEPbuilders] questions about session release and channel close

Simon Raess cocoa at gmx.ch
Tue Oct 24 20:10:50 PDT 2006


On 24.10.2006, at 00:19, David Kramer wrote:

> On Oct 23, 2006, at 2:18 PM, Simon Raess wrote:
>> 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?
> (You confuse channel with session -- I'll assume you meant to say  
> "After all, the peer requested to close the channel...")

Your assumption is correct.

> This can only be answered on a channel-by-channel basis.  The  
> channel profile must specify the correct behavior in this case.   
> BEEP frameworks should delegate this question to the profile  
> implementations.
> If you send a close channel request, and then receive a close  
> channel request, you can choose to reply however you want.   
> Regardless of what you choose, if the remote peer responds to your  
> request with "ok", you must close the channel.  And if you send an  
> "ok" response to the remote peer's request, then the remote peer  
> must close the channel, even if it replied "error" to your request.

I doesn't seem to be "sane" to respond with an "error" in that  
particular case. After all, the peer already decided to close the  
channel. To change that decision, simply because there is a close  
request from the other peer, seems rather strange. But I guess that  
decision will be buried in the implementation. And if I follow your  
following instructions, that will work just ok with other BEEP  

> Once you've replied "ok" to the peer's request, it doesn't make  
> sense to wait for the peer's response to your request.  The  
> response is meaningless.  By sending the request, the remote peer  
> has already promised to close the channel as soon as it receives  
> your "ok" response.  So the remote peer's response to your own  
> request becomes irrelevant.

I see.

> Another way to say this is that once you request a close, you can't  
> change your mind unless the remote peer decides to reject your  
> request.
>> 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?
> I think this is adequately specified.  I do not see any  
> interoperability issues here -- if you request a channel close, and  
> the peer says "ok", you must close it.  End of story.  No wiggle  
> room.  The only grey area is what to do about the second response  
> -- if you have already agreed to close the channel by responding  
> "ok" to your peer's request, and then you receive an "ok" or  
> "error" from your peer in response to your request, I think you  
> should simply ignore the message.  In other words, BEEP peers  
> should always ignore replies to channel-close requests if the reply  
> arrives after the channel has been closed.
> If I'm missing something, perhaps you could clarify what  
> interoperability issues you think could arise between implementations.

My remark about possible interoperability issues was especially  
targeted at the session release process. How to close a channel  
(except when close requests cross in transit) is actually specified  
rather well.

> Thanks,
> David


More information about the BEEPbuilders mailing list