home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / programm / 4414 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  1.9 KB
  1. Path: sparky!uunet!gatech!rutgers!noao!rstevens
  2. From: rstevens@noao.edu (W. Richard Stevens)
  3. Newsgroups: comp.unix.programmer
  4. Subject: Re: SIGPIPE Delivery on socket close
  5. Keywords: SIGPIPE signal TCP socket
  6. Message-ID: <1992Aug23.121615.626@noao.edu>
  7. Date: 23 Aug 92 12:16:15 GMT
  8. References: <1992Aug19.001455.222056@zeus.calpoly.edu> <BtCqCG.DMw@usenet.ucs.indiana.edu>
  9. Sender: news@noao.edu
  10. Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
  11. Lines: 27
  12. Nntp-Posting-Host: gemini.tuc.noao.edu
  13.  
  14. In article <BtCqCG.DMw@usenet.ucs.indiana.edu> jackson@daimler.ucs.indiana.edu (Jeff Jackson) writes:
  15. >
  16. >In the client, after the server has timed out and closed the socket,
  17. >I expected to get a SIGPIPE signal the next time I tried a write to 
  18. >the socket. What I am finding is that the first write that I do to
  19. >the socket completes normally - returning the number of bytes that
  20. >were written. Sometimes even the second write will appear to succeed.
  21. >Usually however the second or third write causes the SIGPIPE signal, which
  22. >is trapped and closes the socket. 
  23. >
  24. >What needs to be done to get the SIGPIPE signal the FIRST time I write
  25. >to the socket? 
  26.  
  27. You are encoutnering TCP's half-close.  The server's closing of its
  28. socket causes its TCP to send a FIN.  That only closes the data flow
  29. from the server to the client.  As far as the client's TCP is concerned,
  30. it can still *send* data to the server.  Your first write will be OK,
  31. but the server's TCP will respond with a RST (since the server really
  32. terminated and didn't do a real half-close), which causes the second
  33. client write to get SIGPIPE.  You can't change this--it's a TCP feature.
  34.  
  35. What you need to do is call select from the client--then the socket
  36. will be marked readable in the client when the server terminates and
  37. your read will receive an EOF.  Use that to not write anything else
  38. to the server.
  39.  
  40.     Rich Stevens  (rstevens@noao.edu)
  41.