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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Andrea replied on 01/27/2003 05:57:37 PM:
> 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).

My take on BEEP was that the Listener
side would reject the BEEP session close if there was still outstanding
I/O on it.  From BEEP, Section 2.3.1.3 The Close Message:

   A BEEP peer may send a "close"
message for a channel whenever all
   "MSG" messages it has sent on that channel have been
acknowledged.

which means that the CUA can try to
close the session after the CS acknowledges the unbounded command.  However
just below that is:

   Otherwise, before accepting the request
to close the channel, and
   sending an "ok" message in a positive reply, it must:

   o  finish sending any queued "MSG" messages on that
channel of its
      own;

   o  await complete replies to any outstanding "MSG"
messages it has
      sent on that channel; and,

   o  finish sending complete replies to any outstanding "MSG"
messages
      it has received on that channel, and ensure that the
final frames
      of those replies have been successfully delivered,
i.e.,

which tells me that the CS wont accept
the session close attempt until it finishes dealing w/the unbounded query;
there may be outstanding response messages to send back still as the command
progresses!.  Im still no BEEP guru so Ill defer to them when Im slapped
and corrected otherwise.

So I still think the only way to terminate
an unbounded command is to drop the connection to the CS.  Ugh!!  Thats
painful and costly...

> Do you have in mind a specific BEEP implementation
which doesn't
> allow you to do clean shutdown? 

No, just my reading of the BEEP RFC...

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

Ok, then how does that not violate the
BEEP RFC cited text above? 

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

You cannot shutdown cleanly if there
is an outstanding command so Im at a loss to see how you did this w/o violating
BEEP.  Is there a BEEP 102 class I can take??

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

IF (a BIG IF) we added a CANCEL command
then Id say NO (KISS!).  You cannot unclick the Cancel button in the
GUI can you?  You cannot unpress Cmd-. can you?  You cannot intercept
the signal to die, etc...

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

Realistically speaking would you pipeline
2 unbounded commands on the same channel??  I would think that you'd
do them on separate channels to get concurrency instead of serialization...

Sighh.... Taking a big step back here
to refocus on the overall picture.

The big motivation for not requiring
bounded latency was described by Doug as being related to some platforms
like Palm not being able to support it.  In doing a search I found
a discussion in relation to alarms or the lack of them on some platforms
so the context was NOT in processing commands but in dealing w/stuff like
triggering alarms.  

I went and got 2 others here including
a Palm owner and did some marker board presentation about CAP and bounded
latency and tried to figure out if this was really an issue for Palms.
 Then we realized that the issue of timing out a command is really
a CS side issue and NOT a CUA side issue per se.  We also could not
think of any realistic case where we would want a command to be attempted
possibly forever given we have no way to abort it.  We could find
none.  We also agreed that its totally unrealistic to use Palm as
an example platform when considering building a real CS given its constraints.

So I must therefore question the CAP
design and the rationale for unbounded commands.  If there is no way
to terminate an unbounded command short of actual termination of the connection
and there is no real world case where an unbounded command is actually
useful then why are we putting them into CAP (and not clearly creating
an in-protocol means to cancel them)??  If we must put unbounded commands
into CAP then there must be some easy way in CAP to terminate them (ie:
CANCEL). 

Arrgh!  My head hirts!  %^|

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...