[BXXPwg] Closing a Channel

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Thu, 23 Nov 2000 09:19:36 -0800


> I'm pondering the actions that should be taken when a BEEP peer issues
> or accepts a "close" request.  My problem is, that a "close" message
> is not synchronized in any way with the message traffic on the channel
> being closed.

exactly. it's entirely up to the beep layer to determine what to do.

for example, in one implementation strategy (for an asynchronous api), the
application gets to indicate whether it wants an "orderly" or an "abrupt"
close.

in the latter case, the beep layer immediately sends the close, continues to
pass up any incoming replies on the channel, but queues any incoming
requests on that channel. when the reply comes in, the "right" thing happens
(i.e., if the close is successful, any queued requests are discarded;
otherwise, they are passed up to the application).

in the former case, the beep layer won't even send the close if it knows
about outstanding transactions for that channel. similarly, if the beep
layer receives a close from the remote peer, if there's anything outstanding
for the channel, it automatically rejects it with an error (and doesn't even
bother passing the close upto the application).

you can imagine a similar set of disciplines for trying to close the session
instead of a single channel.

the short story is that beep doesn't intend to guarantee synchronicity
between different channels, and so it's up to the implementation of the beep
layer to implement whatever discipline is consistent with the application's
wishes...

/mtr