We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible.
There always may be a need to abort a transaction in progress,
by why "out-of-order" and why "as fast as possible"?
I'd strongly suggest to avoid (to prohibit) cross-channel messages.
All transaction processing should be done within the channel where
it has started. Some kind of <transaction-abort> message may come
at any moment as one side of transaction gets an abnormal condition
that makes further processing unnecessary. But there is no "urgency"
in transaction termination - just no need to continue.
I can propose two type of scenarios: A. callout processor gets
unrecoverable error condition (type 500) in situation when OPES
processor keeps a copy of initial message waiting for the next
more-data request. B. Data consumer unexpectedly closes connection
to the OPES server while request processing is in process. In
both cases other side of transaction does not expect transaction-end
message - this is why I propose to have a special message that
can appear at any moment (related to protocol state machine).
But there is no need to expedite transaction termination, this
is just a way out of intermediate processing status.
Can you propose scenarios where out-of-band message
gives significant advantages?
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Thursday, February 27, 2003 1:50 PM
To: OPES Group
Subject: too fast out-of-order messages
No optimization comes for free. Here is a problem with supporting
priority message processing in OPES. I am seeking the group opinion on
how the problem should be handled.
We want to allow out-of-order transaction-dependent messages to be
able to abort an in-progress transaction as fast as possible. This
optimization has a problem: it is possible that the "fast"
<xaction-end> message will be processed by the callout server _before_
the server processes the corresponding <xaction-start> message. If the
current protocol rules are followed, that fast <xaction-end> message
will be ignored because it will not match any known transaction.
Moreover, the transaction may not be terminated at all, until the
timeout happens (which is exactly the opposite of what we want!).
Possible sane solutions:
0) Prohibit out-of-order messages and related
optimizations.
1) Prohibit out-of-order messages until the other
side acknowledges that it received the
<xaction-start> message (and, hence, the
transaction is now known to that other side).
The acknowledgment may be done explicitly
by immediately sending an <i-am-here> message
or implicitly by sending other transaction-dependent
messages as a part of normal operation.
We may even require immediate ACKs.
2) Require <xaction-end> message to always be sent
via the usual [slow] channel, even if another
copy of the message was sent via a "fast" channel.
This way, if fast message is too fast, we have
no optimization but preserve the same semantics.
Same carbon-copy rule can be applied to all
future out-of-order messages. Note that it is
OK to send two <xaction-end> messages because
the second one will be ignored by the recipient.
Personally, I favor (2) because it allows for an optimization, is
simple, has no overheads for those that do not support the
optimization, and does not require creation of the "other side heard
us" state.
I support your choice (2), even in more strict definition:
all transaction processing goes through the same channel on
which it was started. (0) is not an option: there always are
situations when regular processing can not be continued, so there
should be some way out. (1) can not happen if everything goes
on the same channel (in fact it is a good illustration what kind
of problems may be created by asynchronous multi-channel processing).
Note that we can inform implementors that they may _want_ to send
explicit ACKs as an optional feature (they are allowed to do that
already), especially if the callout server does not expect to send any
other transaction-dependent messages for some time. Again, the ACKs
should use existing <i-am-here> messages.
a) I think this is an overkill;
b) reuse of a message in a different sematic context is
usually a very bad thing. In this situation it is very easy to
misinterpret keep-alive message as a confirmation (well, you may
introduce transaction id in keep-alive, but IMHO this creates even
more mess).
Oskar