CODEWITHSUNDEEP
tcpserversocket
Michael Cornel
Michael Cornel

Reputation: 4004

TcpListener stops accepting or accepts broken connections

We currently experience a problem with a self-written server application running on Windows (occurs on different versions). The server listens at a TCP port, accepts connections, exchanges some data and then closes the connections again. There are about 100 clients that connect from time to time.

Sometimes the server stops to work: Log files show that connections are still accepted, but that at the first read attempt a socket error (10054 - Connection reset by peer) occurs. I don't think it is a client issue because it suddenly stops working for all clients.

Now we found out, that the same problem occurs with our old server software, that is even written in another programming language. So it doesn't seem to be an error in our program - I think it has to be some kind of OS / firewall issue? Of course, firewalls have been deactivated, which didn't solve the issue yet.

Any ideas where to look into? Wireshark logs will follow soon..

Excerpt from the log (Timestamp, Thread Id, message)

11:37:56.137 T#3960 Connection from 10.21.13.3
11:37:56.138 T#3960 Client Exception: Socket Error # 10054
Connection reset by peer.
11:37:56.138 T#3960 ClientDisconnected
11:38:00.294 T#4144 Connection from 10.21.13.3

You can see that the exception occurs almost at the same time as the connection is accepted, in this case the client reconnects after a few seconds.

Upvotes: 1

Views: 2088

Answers (6)

Michael Cornel
Michael Cornel

Reputation: 4004

First, thanks for many hints - I'm afraid the problem was a completely different one which you couldn't possibly solve by reading my question.

The server application uses log4net, configured with a log file an ImmediateFlush = true. If every log statement is directly written into the file and multiple socket connections occur this slows down the whole application. The server needed about a minute to really accept the connection. This was far more than the timeout on clientside. So in the log there was only shown "accepted" followed by "disconnected" - even the log was delayed!

Sorry for the inconvenience...

Upvotes: 1

Suroot
Suroot

Reputation: 4423

What do the logs look like from the client side?

Since the error is stating that the client is dropping the connection; if you see the same error on the client side then it is a firewall or proxy that is dropping the connection (both side seeing the opposite side dropping the connection is indicative of a proxy/firewall).

If the error is not present on the client side; then I would say that your client side is where you will see the actual error.

Upvotes: 0

Ross Patterson
Ross Patterson

Reputation: 9569

You don't say what Windows versions you're using for the server, but you should be aware that the Windows TCP/IP stack behaves differently in server and client OSes. There are limits on how many simultaneous incoming connections a client OS will allow, and they are significantly lower than you might expect.

Upvotes: 0

tc.
tc.

Reputation: 33592

A "stateful" firewall or NAT keeps track of connections, and ought to send RSTs for connectiosn it doesn't know about. If the firewall loses track of connections for some reason, then you'll probably see random connections being reset.

Our router at work does this — it forgets about connections when the PPP connection dies, which is remarkably unhelpful when it rains and the DSL restart takes a bit too long. However, instead of resetting connections, it just drops packets (even more unhelpful!).

Upvotes: 5

MARK
MARK

Reputation: 2362

Have you tried changing the backlog and then see how much time or how many clients are served before this problem occurs

Upvotes: 0

weismat
weismat

Reputation: 7411

Sounds like a firewall or routing issue - maybe stale connections get disconnected after a timeout period. Are you using a ping/keepalive inside your protocol.
Otherwise you may ask Wireshark to see what is going on.

Upvotes: 1

Related Questions