Fog Creek Software
Discussion Board

Killing an Orphaned TCP Socket

Has anyone got some sample code for killing an orphaned TCP Socket ?

Wednesday, May 7, 2003

Wednesday, May 7, 2003

Please define "orphaned TCP socket".

Chris Tavares
Wednesday, May 7, 2003

By Orphaned TCP socket I meant a "ghost session"
when the socket was not properly closed
(usually because the client has crashed)

Wednesday, May 7, 2003

Use shutdown() then closesocket()

Wednesday, May 7, 2003

Ok but How do I get the handle of a socket ?

Wednesday, May 7, 2003

On un*xes you might try a software call lsof.. or ntop.

Li-fan Chen
Wednesday, May 7, 2003

What OS? I find it hard to believe that there's a modern OS out there that doesn't notice a process with a socket has disappeared, and thus sends a reset to the other side.

Or perhaps you mean that the connection is in TIME-WAIT, of which there is no recourse. It's TCP.

Brad Wilson (
Wednesday, May 7, 2003

Use TCPView. Free dowload from

Just me (Sir to you)
Thursday, May 8, 2003

I'm not a networking god, but I've developed some pretty serious socket based apps that are currently in production. One project is a financial app that is used by traders all day (sockets opened 8-10 hours at a stretch) and is used continuously, 6x24, four continents a day. It's been very reliable for the six years it's been in use.

Off the top of my head, they all do something essentially like this, in both the clients and the servers:

try {

    Object o = socket.readObject();"received:"+object.toString());
} catch (Exception ex) {
  Log.error("exception reading socket", ex);
  try {
  } catch (IOException iox) {
      Log.error("exception closing socket", iox);

(The exception handling is probably more specific and complex, but if you catch those two, you're OK.)

If either side close()s, an exception will get thrown immediately at the other end. FWIW, These are stream sockets. I've never done any multicast stuff. Guaranteeing that you call close() is the key. You need to make sure to do that if write()s fail, as well.


I added the Log statements to show an important principle for distributed apps. Always log immediately before and after network sends and reads. Trust me, this will save untold amounts of grief. I started doing this years ago and it helps troubleshooting *a lot*. It's absolutely essential if the clients and servers are written by different people. Unfortunately, I'm currently running a production support team for a bunch of apps that don't do this and it causes me no end of frustration. I spend all day getting involved in this kind of knuckleheadedness:

Me: Bob, where's the problem?

Bob: It's in Tom's end, he's sending me the wrong stuff.

Me: Tom, where's the problem?

Tom: It's in Bob's end, I'm sending him exactly what I'm supposed to.

Me: Bob, can you show me what you got from Tom?

Bob: Here's what we see.  [From a log from some component three layers away from the actual network operation with lots of translation, probably buggy, in between.]

Me: Tom, can you show me exactly what you sent?

Tom: Sure, it's this database record right here. [Again multiple layers of probably buggy software in between this view and what actually gets sent on the wire]

Me: Please, someone, just shoot me.

While I'm ranting, be sure to include some messaging to control the operation and diagnostics of your programs, both clients and servers. Make sure you can close any socket via messages, without having to bring your app down and make sure you can bring the app itself down by sending it a "shutdown" message. It's a very powerful way to build distributed apps and will be much easier in the long run than relying scripts or "kill"


Jim S.
Thursday, May 8, 2003

JustMe :

If you've got TcpView source code then I'm interested ;-)

Thursday, May 8, 2003

You need correct handling for SIGCHLD or you will get zombies.

If you're doing socket programming, it's time to go Unix Network Programming by Stevens.

S. Gwizdak
Thursday, May 8, 2003

"The complete source for the command-line version of TCPView, netstatp, demonstrate the IP Helper interface and is available here for download."

Just me (Sir to you)
Thursday, May 8, 2003

Can you remotely close a sockets
from a client on a server (on which u do not have admin rights) and the socket is not associated with ur client but another

Thursday, May 8, 2003

You can't.

You would need to
a) look into one of the packets going from the client-you-wish-to-shut-down to the server
b) send packets from your own machine with fake source IP addresses

Tuesday, May 13, 2003

*  Recent Topics

*  Fog Creek Home