Detect Socket Hangup Without Sending or Receiving

Detect socket hangup without sending or receiving?

I've had a recurring problem communicating with equipment that had separate TCP links for send and receive. The basic problem is that the TCP stack doesn't generally tell you a socket is closed when you're just trying to read - you have to try and write to get told the other end of the link was dropped. Partly, that is just how TCP was designed (reading is passive).

I'm guessing Blair's answer works in the cases where the socket has been shut down nicely at the other end (i.e. they have sent the proper disconnection messages), but not in the case where the other end has impolitely just stopped listening.

Is there a fairly fixed-format header at the start of your message, that you can begin by sending, before the whole response is ready? e.g. an XML doctype? Also are you able to get away with sending some extra spaces at some points in the message - just some null data that you can output to be sure the socket is still open?

How to fix the Socket Hangup Error when large number of requests are made really quick

There are many reasons for socket hangup/reset in production apps. From your description I believe the cause isn't due to app overloading with requests (unless you're running a very slow machine).
IMO, the most likely candidate is throttling by remote server due to too many connections from same ip (chrome opens upto 8 connections to any single server, you should try not to exceed this limit, despite each server having different limit), to solve this you should do one of the following:

• add host request pooling (basically set Agent.maxSockets)
• use proxy service (e.g. Luminati) to distribute requests over many source ips (more relevant for high concurrency requirements)

One more thing to remember, requests can fail for 'natural' networking reasons (e.g. bad\unstable internet connection, server busy spikes), you should always do at least one retry of request before giving up.

why socket on the receiving peer keep receiving '' infinitely when I use control-c to close the socket on the sending peer

I know it's a bad habit to close socket using "control-c"

That closes the entire process, not just a socket.

why socket on the receiving peer keeps receiving '' infinitely after I use "control-c" to close the sending process?

At a guess, which is all that is possible without seeing the code you should have posted in your question, you are ignoring errors and end-of-stream when calling recv().

shouldn't the socket on the sending peer be closed after "control-c" to exit the process?

It is. The whole process is 'closed', including all its resources.

As regards the receiving socket, it is up to you to detect the conditions under which it should be close, and close it.

---

Related Topics