Path: utzoo!attcan!uunet!wuarchive!sdd.hp.com!samsung!umich!sharkey!amara!mcdaniel From: mcdaniel@adi.com (Tim McDaniel) Newsgroups: comp.unix.programmer Subject: Server death detection? Message-ID: Date: 18 Oct 90 15:14:27 GMT Sender: news@adi.COM Organization: Applied Dynamics International, Inc.; Ann Arbor, Michigan, USA Lines: 34 My coworker has a problem. (Well, actually, he has lots of problems, but only one concerns us now. 8-) He's got a server and a client talking via sockets over a network, running under ULTRIX 4.0 and/or SUN OS 4.1. At some point, the server is killed. He would like the client to receive notification ASAP that this has occurred. SIGPIPE only happens when the client tries to write to the server. select is no help at all: the death of the other end of the connection is not perceived as an exception. There does not seem to be a setsockopt option for this. His current workaround is to have an alarm occur every N seconds. In the signal handler, he will attempt a non-blocking peek mode receive. If the server died, it'll return an EOF. If not, it'll return -1 with EWOULDBLOCK. There are two minor concerns with the latter approach. One is the overhead if N is small. The other is that the communication stuff is in a library, and he has little control over the caller. If the caller pauses, it'll get interrupted by the alarm; every program using this library must therefore check, after each pause, that the condition being awaited has occurred. This is good UNIX programming practice, but he has no way to enforce it. In general, the workaround is a bit unclean. He'd like the mechanism to be immediate and silent to callers. Is there a better way? -- Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Work phone: +1 313 973 1300 Home phone: +1 313 677 4386 Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel