Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!xtel.co.uk!j.onions
From: j.onions@xtel.co.uk (Julian Onions)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re: Why does ISODE use SO_KEEPALIVE?
Message-ID: <16089.659086127@xtel.co.uk>
Date: 20 Nov 90 07:28:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 29

A couple of cases where KEPP_ALIVES are useful.

A client opens a connection and asks questions of it. The server replies.
The client goes away and does something with this information intending to
ask the server more questions in the future over this connection it has open.
Meanwhile, the client machine crashes.
The server will not get to know about this I believe as it will not try
to actively use the connection, it is waiting for input.

Another case is a client, that wants to connect to a client to indicate
it wants certain events. Client connects to server, and says send
me all events of type X down this connection. Both sides sit back and wait.
The server machine crashes or is taken down and rebooted.
The client is unaware of this as no activity is taking place over the
connection. It thinks it still has a registered handler for events of type
X which are now being thrown away. If it detected the server machine had died
it would have tried to actively reregister.

Now both these cases can be solved either by keepalives, or through
higher level NOP operations. The difference is that if I'm using
X.25 I get to know about these events for free. If I'm using TCP I have
to go out and look for them. Any application where I might get into this
situation I have to add NOP operations to the protocol and a suitable
timer. As an applications person, it seems like its not my job to
write into each application specification a KEEP_ALIVE functionality.

Session layer for TCP anyone?

Julian.