No connection could be made because the target machine actively refuse it RRS feed

  • Question

  • I have an network socket application (Client-Server application). Sometimes my client application having trouble to connect to server and throwing a SockectExeption with the "No connection could be made because the target machine actively refuse it" message. This situation continuing for a while like this (for example 10 min) and eventually it can connect to the server successfully. In the server side I don't have a fail safe mechanizm to restart listening for the port. And there is no any accept connection call in the application level. I'm thinking that in the socket level for a reason OS stopping to accept clients and recovering it by it self.

    I need help to find out what is the problem and how to resolve it.

    Note: It's a huge application and there is a possibility to a huge data transfers between clients and server. When the socket cache is full is it possible to cause this kind of problems?

    Wednesday, April 1, 2020 1:17 PM


  • This can happen for a number of reasons but the most common cause is that the server (your app) is busy and not responding to connection requests). This can happen if you aren't using async accept requests, if you are accepting connections but then trying to do work on the same thread (which blocks subsequent accepts) or if your listening thread stalls. It could also happen if your server gets too many requests at once cannot process them fast enough. There is a limit on how long a connection request can take.

    But all this is on a new connection. In most TCP client/server apps the client will connect to the server once and then use the provided socket for all subsequent requests. In this mode each socket has its own buffering and connection and therefore the fact that one client is busy on a socket would have no impact on any other client or connection requests. However, again, this is completely dependent upon how you implemented your server. Your server should be listening for connection requests on a dedicated thread. When a connection request comes in it needs to immediately move that connection request to its own thread and start listening for more connections (or use the async accept logic). This allows the server to keep listening. Thus each client has its own thread to communicate on the server and the server shouldn't have issues.

    You are limited to the # of threads per process you have. For an x86 process you can get around 2K threads. If you are accepting 1000s of connections at once this is unrealistic. Therefore you need to implement thread pooling for connections. So rather than each connection getting its own thread you have a pool of threads. Connections share threads. When a connection needs to send/receive data it grabs one of the thread pool threads to do its work. When it is done the thread is returned to the pool. This is not trivial code to write but it is how web servers can handle 1000s of connections at once. If you are using this kind of implementation then a failure can occur if you run out of available threads to process requests.

    Unfortunately there isn't much we're going to be able to do to help you actually figure this out as we have no insights into your code. You are going to have to load test your server. If you are seeing clients unable to connect then take a look at your server. If it is has lots of sockets and threads then you might be swamping the server with resource requests. Perfmon and Task Manager can help identify this. TcpView can help with viewing the network connections. If the calls are simply taking too long and timing out then you need to look at what your server is doing for requests and ensure you aren't deadlocking threads and/or trying to do to much on a single thread (e.g. connection management and send/receive logic).

    Michael Taylor

    Wednesday, April 1, 2020 3:37 PM