home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!opl.com!hri.com!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!void!ejohnson
- From: ejohnson@void.ncsa.uiuc.edu (Eric E. Johnson)
- Newsgroups: comp.unix.wizards
- Subject: Re: Detection broken tcp connection
- Keywords: tcp connection broken
- Message-ID: <ejohnson.728168994@void>
- Date: 27 Jan 93 21:09:54 GMT
- References: <wv.728144099@bambam>
- Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
- Organization: University of Illinois at Urbana
- Lines: 31
-
- wv@dasc.nl (Wouter Visscher) writes:
-
- >The manuals are not to clear on this subject, testing showed the above calls
- >i.e. select, send, recv did not return error codes indicating a problem.
- >Mind you if an error code is only return once I might have missed it during
- >this test
-
- Lucky you. I just learned the answer to this question last week.
-
- If your sockets are...
-
- Blocking... then just wait for a read to return zero bytes, indicating a
- broken connection. I don't use blocking sockets, so I have no
- experience with this method.
-
- NonBlocking... Watch for select() to claim that one of the sockets can
- be read from by setting the appropriate descriptor bit. Then, when you
- go to read the socket via a non blocking read, you will get zero bytes
- back when the socket connection is broken. Keep in mind that normally,
- a zero means, "No new data". It only means "Broken connection" when
- select() indicates that the socket should be read from.
-
- This should do the trick.
-
- Eric
-
-
-
- --
- Eric E Johnson | "Sigsoft is a black hole of ambition, everything
- ejohnson@a.cs.uiuc.edu | gets sucked in, and nothing comes out." - Me
-