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