Subject: Re: Request/response pairs

From: jfcm <[email-masked]>
Date: Mon, 17 Feb 2003 10:48:53 +0100

On 18:33 16/02/03, Martin Stecher said:
>Hi.
>Yet two other questions regarding OPES request/response pairs:
>- Should the protocol require that there is always a response to each
>   request?
>
>   While writing the ICAP extension draft, I was informed about an
>   additional method for logging that has been introduced.
>   This method sends only "requests" (better notifications) to the
>   server (to give a REQMOD service information about the downloaded
>   object from a former REQMOD request for logging purpose).
>   This method does not expect any response.

The main problem of Internet is the lack of acks. Please let not
repeat it in here. But there may be smart schemes to get virtual acks,
however we want to avoid being out of sync. I do not see how you
can do that except with a timer on an ack if there is no other
exchange.

>   Are these messages w/o response something the OPES protocol should
>   consider or allow or forbid explicitly?
>
>- While connections MUST only initiated from client to server, what is
>   about requests on that connection?
>   May it be useful to allow the callout server to send a request back
>   to the client?
>
>   I am thinking here about the keep-alive messages?
>   It is not only in the interest of the OPES device to check whether
>   the server is still alive. The callout server could also be concerned
>   that no new request is coming along an open connection and wants to
>   verify that the client is not down.

This is necessary. But these mesages are different nature. They
basically maintain a link with a (virtual) machine. They MUST
be initiated by the server (or how the client is to know that the
server does exist) either as a point to point or as a boradcast.

"hi! clients for service "so and so" I am alive.".

Introducing a DNS like on this seems to be a complex
move, an OPES must ract very fast saying if it can or not assume
he service it will delegate to the server.

jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03