Re: CAP 10: 10.1. CAP Commands (CMD) (ABORT/CONTINUE)

[Andrea Campi <a.campi@xxxxxxx>]

On Mon, Jan 27, 2003 at 04:06:40PM -0500, Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> Andrea noted on 01/24/2003 12:03:39 PM:
> > For that matter, since we're using BEEP, it can simply close the
> > channel and open a new one, no need to drop the session.
> 
> Sure thats just as valid. 
> 
> It does however have the undesirable side effect of keeping the unwanted, 
> unbounded, uncontrollable command going since the CUA is still connected. 
[...]
> I would expect that a good CS would take steps to make sure to detect CUA 
> disconnect and deal with it like aborting in progress commands, doing 
> session related cleanup, etc.  Having the CUA create a new channel though 
> would NOT cause the same to happen so the unbounded command would continue 
> its rampage...

I agree opening a new channel wouldn't cancel outstanding commands -
but closing one had better! I'm not talking about forcefully
dropping a connection; rather, about sending the other party a
notification that we're about to close (or that we'd like to close
it, if you prefer; a BEEP peer could still deny the request, as you
mentioned).
Do you have in mind a specific BEEP implementation which doesn't
allow you to do clean shutdown? The one I'm using most surely does,
and my CS is taking advantage of that (even the very dumb one I
am going to release as part of libical).
Of course, once your server is notified of the channel shutdown,
there's still the problem of actually stopping the runaway
process - but this depends solely on your server architecture.


Anyway - I'm not advocating that we should go this way. It's just
that any alternative gets complicated pretty quickly. After all,
it seems to me aborting a command should be an exceptional event
(like the CU pressing a cancel button on a 'wait' dialog, or
outright quitting the app) and less common than use of bounded
latency.
For instance, imagine we add a CANCEL command. First of all, if
there are multiple channels open, where do we send it? On the
same channel I guess, but what if the CS was stuck in a state
where it doesn't react on that channel only (quite possible in
a multithread server)? Or do we introduce the concept of a control
channel (I hope not, and forget I mentioned the possibility)?
Should we put a latency on CANCEL as well?
Also, what if we have several outstanding commands on the channel?
We would need to use the ID parameter together with CANCEL - but
then if a CUA wants to be able to cancel all commands it needs
to keep a list of them (ok, it probably needs to keep the list anyway)...

OTOH, if you see this as a non-exceptional mechanism - that is,
a peer might opt to use CANCEL commands as an alternative or in
addition to LATENCY in normal operations - then we have two ways
of doing the same thing (since you can always transform a timed
abort into an immediate cancel or viceversa).


Bye,
	Andrea

-- 
Andrea Campi                              mailto:a.campi@xxxxxxx
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy