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

From: "Martin Stecher" <[email-masked]>
Date: Wed, 5 Jun 2002 18:41:41 +0200

Regarding Section 3.5 Support for Keep-Alive Mechanism
"The OPES callout protocol MUST provide an optional keep-alive mechanism
[...]"

Is this really a MUST?

As I understand the section the keep alive mechanism has to belong to
the OPES protocol not to the lower-level transport protocol.
So, a possible implementation would be that the data processor opens a
channel (let's say it is a TCP connection), keeps it open forever and
sends and receives protocol keep alive messages in absence of any real
transaction, so that both data processor and callout server will know
that the other peer is alive.

While this is a great idea and good for a SHOULD requirment, I do not
see why this is a MUST.

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.

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.

Martin

---

From: Andre Beck <[email-masked]>
Date: Wed, 05 Jun 2002 15:13:31 -0500

Hi Martin,

 > 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).

 > negotiation messages from time to time to check a callout server's

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

-Andre