ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-27 12:14:36

On Thu, 27 Feb 2003, jfcm wrote:

My use/understanding of zap is initial pipe oriented. Clean the
"thing" tree from that pipe.

Using 100 times zap is totally acceptable. Actually this is the best
way to synchronize. zap means swallow everything related to this
pipe, clean it. Nothing in there, what ever it was. Clean buffers.
Signal attached tasks to die propagate along the pipes all over the
network. Or the equivalent (I use the image of my old QNX based
system). May be I was wrong in assuming that it corresponded to your
commands.

There are no connection-oriented commands in the predraft yet!

What you want is entirely different from a <xaction-end> message. You
want to kill every transaction that is associated with a given OPES
connection. You want <transactionS-end ...> message that has no xid
(because it applies to all transactions on the corresponding
connection).

<transactions-end> is an optimization. It is semantically equivalent
(almost) to sending multiple <transaction-end> messages, but is
smaller. I will add <transactions-end> to the TODO list. We need to
decide what to do with OPES connections in general before we can zap
them.


Moreover, you want to clear all unprocessed connection buffers which
should be a different command because it has a different semantics.
All implementations can support <transactions-end> message and only
very few (or none, depending on allowed OPES bindings and message
encodings) can support buffer flushing. For example, if OPES messages
are encoded in raw XML, then you may not be able to flush buffers
because you may create partial messages and may not be able to find a
beginning of the message after that.

IMO, this buffer-flushing command is too low-level for OPES. Simply
closing and re-opening the connection is probably more appropriate and
is not much more expensive. I suggest we wait for other opinions
before proceeding with this.

So for example zap 0 would kill the network and restart the network
establishment negociations, etc. Next to power down it is the
"reboot" of the network.

This is even more than flushing buffers. You want to close and reopen
connections as well. I think this should wait until we add connection
management framework to the protocol. We need to decide whether and
how OPES connections can be reopened and what effect a suddenly closed
connection has on the other end.

Thank you,

Alex.