Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: anund@idt.unit.no (Anund Lie)
Newsgroups: comp.sys.sun
Subject: RPC server -- How to detect death of client?
Keywords: Miscellaneous
Message-ID: <1972@brchh104.bnr.ca>
Date: 18 Mar 91 17:28:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 21
Approved: Sun-Spots@rice.edu
X-Original-Date: Fri, 1 Mar 91 16:09:01 +0100
X-Sun-Spots-Digest: Volume 10, Issue 57, message 8
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

When running Sun RPC over TCP (or other connection-oriented services, for
that matter), how can the server detect that a client process has died?
(More precisely: That no process has the other end of the connection
open.)  

On the socket level, this will be detected by a read() on the socket
returning 0 (end-of-file).  The best thing would be to be able to register
a procedure or in some other way control the action to be performed when
RPC detects EOF on a socket.  (It has to detect EOF anyway and close its
end of the socket, hasn't it?)

The manuals does not mention this, but /usr/include/rpc/svc.h (SunOS 4.1)
defines the operation SVC_STAT().  Presumably the (pointer to) the
transport handle could be saved at the first call from a new client, and
the server periodically SVC_STAT() the set of active handles.  Is this a
reasonable thing to do?  There does not seem to be any guarantee that
transport handles are unique over different RPC calls, so that it is OK to
store them in this way.

Anund Lie
Email: anund@idt.unit.no       (Internet)