ietf-openproxy
[Top] [All Lists]

Re: AW: too fast out-of-SENT-order messages

2003-02-28 13:38:51

On Fri, 28 Feb 2003, Martin Stecher wrote:

It seems that I misunderstood the whole concept.

I am glad you asked these questions, then! Clearly, predraft needs to
do a better job at defining OPES messages.

I thought a transaction could be more than a single request-response
pair.

It could be, depending on the application protocol. This is an
_application_ transaction we are talking about here. For HTTP, an
application transaction could be a (request, response) pair or it
might be all messages related to the same (persistent) client
connection, or server connection (less likely).

Note that some protocols (e.g., HTTP) do not define a clear
transaction boundaries. In those cases, it will be always up to the
OPES dispatcher what to call an application transaction, I guess.

I thought when the OPES processor opens a transaction it tells the
callout server what to do with all following application messages,
e.g. <xaction-start "URL-classification for HTTP requests">
following hundreds of HTTP requests before the transaction stops.
That would have been a nice way to reduce the exchange of always the
same meta data.

You seem to be thinking about OPES transactions here. Those are not
(yet?) defined in predraft version of the protocol.

We need application transactions and application messages as OPES
"objects" because a lot of processing state (metadata) will be
associated with them. We may also need OPES transactions because, like
you said, there may be lots of state associated with them as well. We
already have OPES messages, of course.

I was thinking that OPES transactions might correspond to OPES
connections. That is why I did not introduce them into the draft yet,
waiting to hear more opinions on the connection management issues. It
is probably about time for me to make a specific proposal though.


In your experience, what kind of metadata/state would be associated
with an OPES transaction (separate from the application transaction)?
Same service IDs? Dispatcher- and callout-server-specific
info? Anything else?

Thank you,

Alex.

P.S. Perhaps we should change "xid" to "axid" to emphasize that
     it identifies an Application transaction.

<Prev in Thread] Current Thread [Next in Thread>