Re^2: How to monitor TCP Resets using Sockets

In general the way to detect a closed socket is: upon write - handle the SIGPIPE signal. Upon read, use a time out. This doesn't appear to be what the OP is describing.

Basically, if you are a "writer", you can tell very quickly that the pipe is not open anymore for write (although there may still potentially be stuff in it that hasn't been read yet).

However if you are "reader", you can't tell the difference between "my partner is really slow" and "he isn't there anymore". You have to conclude that "he isn't there anymore" when he is really, really slow. It is possible to still be reading even after your partner has long since died, and the socket is closed as far as he is concerned.

If I am controlling the protocol at both ends, and it is possible for me to do so, I will send an "in-band" signal (Maybe a CTL-D or whatever) to the client to let him know that "I'm done and signing off". This is done to circumvent the client time-out.

An "in-band" signal is part of the data stream which the client has to parse. An "out-of-band" signal, like a SIGPIPE signal (for the writer) is not transferred via the data communication stream.

There simply is not an out-of-band signal to notify the receiver that the transmitter has "gone off the air". "The BBC concludes our nightly broadcast" is the way that it is done - that is an example of an "in-band" signal.

Comment on Re^2: How to monitor TCP Resets using Sockets

Replies are listed 'Best First'.
Re^3: How to monitor TCP Resets using Sockets by zwon (Abbot) on Dec 31, 2011 at 09:47 UTC
Dude, you have no idea what you're talkin about! you can't tell the difference between "my partner is really slow" and "he isn't there anymore", BUT you can easily tell when it is properly closed TCP connection, because recv will return after reading 0 bytes, and this is how you usually know that connection is closed. P.S.: ~~I'm keen to see example of how you would send SIGPIPE via TCP ;)~~, after rereading it seems that by out-of-band you mean something not related to TCP out-of-band data	[reply]
Re^4: How to monitor TCP Resets using Sockets by Marshall (Canon) on Jan 02, 2012 at 04:28 UTC
There are just too many unknowns in the OP's question for me to be of more help! Some code would go a long way towards clarifying things! I think we can both agree upon that! Network Programming in C is a full 4 hour college level class. So this is not an "its easy, learn it over the weekend subject". Getting this stuff to work "most of time" is not that hard. The complicated parts all involve these "yeah, but", "what happens if," situations. Perl is a bit different than the C functions. Without some code, I can't tell what the OP is actually doing. I looked back and found a Perl version of one my C client readn() routines that reads fixed length packets. Getting a zero byte return is not necessarily an error. Getting a -1 in C or undef in Perl is an error. My C version just returned the -1 error. Here I sent the USR1 signal to myself just for grins to play around with it. I didn't keep my test report, so I can't prove that this works without some re-testing and having to post much more code. There could very likely be a "hole" in it. It is completely possible for the "writer" to have already died while stuff is still available for the "reader" to read. I'm not at all sure what this "reset from the server" means - how the client is supposed to learn that and what it is supposed to once it does. There are various ways to do the reads: blocking/non-blocking and flavors thereof. `sub readn { my ($socket, $bytes ) = @_; my $offset = 0; my $buf = ""; while ($offset < $bytes) { my $nread; my $nleft = $bytes-$offset; $nread = sysread($socket,$buf,$nleft,$offset); ## undef is like the -1 C return kill 'USR1',$$ unless (defined $nread); last if ($nread ==0); ## EOF $offset += $nread; } return $buf; }` [download]	[reply] [d/l]