On Wed, 26 Feb 2003, jfcm wrote:
No. The question was about parallel command pipe or not. My response
was to try to see if we can have a consistent response. Obviously
triggering a command should probably go the same way as aborting it.
If I understand the above, that is what the current predraft proposal
does. Triggering transaction processing on the other end uses the same
mechanism as aborting that processing (an OPES message with the
corresponding transaction ID xid).
The idea of a piped protocol being accepted, you must zap the pipe
if you want to abort. This means a priority somewhere in the
processus. Either in the pipe with a zapper swallowing the data. Or
a prioritized command pipe ordering to clear the four buffers.
Priority processing is not required to terminate a transaction.
Priority processing is an optimization -- it allows to terminate
transaction on the other side _faster_. How much faster? Depends on
how exactly one organizes priority queues and on how long those queues
are at the abortion time.
If you recall, the predraft protocol allows for out-of-order (i.e.,
prioritized) commands but does not document how the transport
connections are handled (yet). If a OPES processor opens more
connection to the callout server than there are concurrent application
messages, then a <xaction-end> message can be sent using "spare"
[control] connections, possibly triggering a faster abort.
I do not know what you mean by "zapper swallowing the data" in the
pipe. Can you clarify, please? Since we are talking about TCP-like
connections here, it may not be possible to "swallow" anything that
was sent. The only reliable option is to ignore messages with unknown
(e.g., already aborted) xid and/or terminate the corresponding
transport connection. Perhaps that's what you meant by swallowing?
Then there is the message telling the server to abort and and ack to
the requester.
An ACK would be a waste of resources unless you want to support OPES
transaction resumption after the event of transport-layer connectivity
loss. By "resumption", I mean resuming at the place of last
synchronization, transparently to the consumer and producer.
I doubt the benefits of transaction resumption outweigh increased
protocol complexity. It seems to me that for application protocols we
know about (HTTP and SMTP), an application transaction abort or an
automated retry would be more appropriate solutions. Do you think OPES
transactions should be resumable if the transport layer fails?
The real issue is that at minimum there are four flows involved
user/dispatcher/service/dispatcher/organizer in my own words instead
of one. Following all the possiblities calls for an Excell
spreadshit.
In such cases, a higher level simplification or abstraction often
works better than enumerating endless possibilities in a table (IMO).
The proposed OCP protocol is such an abstraction (at this point in
time) because it does not really care what the consumer, producer,
source, or destinations are. The number of flows is not important as
long as all flows are mostly independent and there is a well-known
"forking" or "initial scheduling" point (the OPES processor in our
case). The proposed protocol handles at least two flows per
application transaction and should scale well with the number of
flows.
Alex.