| [reply] |
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.
| [reply] |
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] |
Wow..that is strange. Can you show some code that reproduces this?
Maybe you are getting a SIGHUP signal?
You appear to be describing what would be called an "out of band" message - something that that is not coming via the socket? | [reply] |
Oh, what a mess. SIGHUP is generally have nothing to do with sockets, in case of out-of-band data you would receive SIGURG, and this out-of-band data will come via socket.
But OP is seems concerned about TCP packets with RST flag set, which is not the same as OOB. I'm not sure why OP needs it, but if he really needs to count TCP packets with RST flag he can use something like tcpdump, or Net::Pcap, or learn about raw sockets. I would use C to deal with it, but it depends on exact problem, which OP doesn't share with us.
| [reply] |
