[ Table Of Contents ][ Answer Guy Current Index ] greetings   Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12 [ Index of Past Answers ]

(?) The Answer Gang (!)

By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!
Send questions (or interesting answers) to The Answer Gang for possible publication (but read the guidelines first)

(?) How Do You Detect if a Server Closed a TCP Connection

From Sree

Answered By Chris Gianakopoulos, Thomas Adam, Ben Okopnik

hi group,

I have a client here that is communicating with a server socket.

(!) [Thomas] Hi,
[** I'll give this my best shot, but my knowledge on this is limited **]
(Hey...perhaps I ought to invest in some Dark Sunglasses like our "shady" KGB counterpart)
(!) [Heather] The Editor Gal hands the Weekend Mechanic his toolbox and welding goggles...

(?) The client is transferring data to the server. If the server closes the connection after sometime ,how can the client know that the server has closed the connection.

(!) [Thomas] You could try periodically pinging the server, and if you get "timed out", then you know that the connection has terminated.

(?) The write fails, but how can the client know that it is because the server closed the connection or is due to some other error.

(!) [Chris] If the client were doing a read on the socket, it would get an end of file indication when the server closes the connection.
When the server closes its end of the socket, a TCP FIN segment is sent by the server side. The client's TCP will send an ACK segment, and the client will be given an end of file on its next read of the socket. Under this TCP half-close situation, the client can continue sending data to the server. When the client is finished writing its data, it then closes its end of the connection. The client TCP then sends a TCP FIN segment, and the server TCP sends an ACK segment.
I'm surprised that an error occurs during a write to the socket when the server closes its end of the connection. I'm not sure what happens under the scenario that you are describing, but, the variable errno should give some indication of the type of error that had occurred. I cannot remember off hand what the error code would be.
But the shutdown() command (associated with sockets) must be used for this half-close situation to occur. Also, the literature states that very few applications use the half-close feature of TCP.

(?) Is it correct to assume that the server closed connection if the write fails?

(!) [Thomas] No....it is not correct to assume this. It could be either machine that closes the connection. Perhaps the client closed the connection because of over loading the data buffer????

(?) In my program I have to sense that the server has closed connection and should try to reestablish the connection.

How can this be done..?

please help...


(!) [Thomas]
In which language are you writing this program??? If it is in Perl, Bash, Ada, then I can try and help.
(!) [Chris] I was just reading my "Unix Network Programming" textbook, and it mentions that if the connection is terminated, a signal, with a value of SIGPIPE, is sent to the process that tried to perform a read on socket.
Sooo....., I snooped around on Google, and found a URL,
It shows some "C" code that, I think, confirms what I believe. A SIGPIPE signal will be generated and sent to the process that initiated the write on the socket with the now closed server connection. The client would just to catch the signal, and the event would be detected, thus, the client could perform its desired response to the event (the server terminating the connection).
(!) [Ben] I've read up on this stuff since, and I believe that you're right - as long as it's understood that it's not the server itself that sends the SIGPIPE; it's part of the IPC, which is handled by the kernel. As an example, here is The Proper Way to raise a kid who reads:
  # Open a buffer to be dumped to a process; defined by the leading "|".
  open SPOO, "|txt2gif 2>/dev/null" or die "Can't fork: $!\n";

  # Declare a local trap; $SIG{PIPE}'s current value is saved and will be
  # restored on exit. This is the part that most folks forget to do.
  local $SIG{ PIPE } = sub { die "ENOTOBACCO: Broken pipe error!\n" };

  # Send some STUFF to the buffer; unless autoflush is enabled, the data
  # will just sit there until...
  print SPOO "Bar foo fraggle garp\n";

  # ...we actually flush it into the pipe, here.
  close SPOO or die "Bad spool: Papa spank! $? $!\n";
(!) [Chris] If I messed anything up in this, feel free to jump and give me a good wack up the side of my head with a dead weasel (as Ben O. would say).
(!) [Ben] Hey, hey! <virtuously> Don't blame your weasel addiction on *me.* You must take full responsibility for your own actions, or you'll never get that mustelid off your back.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 76 of Linux Gazette March 2002
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

[ Table Of Contents ][ Answer Guy Current Index ] greetings   Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12 [ Index of Past Answers ]