RE: OPES protocol, pre-draft 01

> -----Original Message-----
> From: 
> Sent: Friday, February 28, 2003 1:08 PM
> To: 'Alex Rousskov'; ietf-openproxy(_at_)imc(_dot_)org
> Subject: RE: OPES protocol, pre-draft 01
>
>
>
> See inline,
>
> Abbie
>
> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
> > Sent: Thursday, February 27, 2003 2:15 PM
> > To: ietf-openproxy(_at_)imc(_dot_)org
> > Subject: RE: OPES protocol, pre-draft 01
> >
> >
> >
> > 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!
> --- Abbie, that is correct.
>
> > 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.
> ---ABbie
> In TODO list is a good place for it.
> > 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.
> ---Abbie, ALex, Amen, let us keep the vry low level out. 
>
> > > 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.
> --- Abbie, Yuk......
>
> > 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.
> ---- Agree
> >