ietf-openproxy
[Top] [All Lists]

Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt

2002-06-05 13:16:13

Hi Martin,

>>From other sections we can learn that we are looking for a real client
> server protocol, in which only the data processor establishes the
> channel and the callout server MUST be able to handle many different
> channels from different data processors and so on.
>
> Since HTTP is a good example for such a protocol in general, the callout
> server is like an HTTP server and is typically not really concerned if
> some clients fail and do not longer send requests for some time. When
> all connections are closed, the server can free its resources.

True, but the difference is that HTTP servers typically can use some sort of time-out mechanism to close idling persistent connections and free resources. Callout servers can't do that because such a behavior could result in the loss of application message data and the OPES processor may not necessarily be able to repeat a callout request (since it cannot always keep a copy of application messages).

Also, unlike HTTP servers, callout servers will have to maintain state information for callout channel connections (mostly negotiated channel parameters).

> On the other hand, the data processor is probably very much interested
> in knowing that a callout server has a failure even in times when no
> transaction has to be handled (in order to start some failover actions).
> But for this task the protocol still does not stringently needs the
> keep-alive mechanism but could also reuse the must-have parameter
> negotiation messages from time to time to check a callout server's
> availability.

Yes, this would be feasible (but not necessarily very efficient).

-Andre