Why the TCP server socket is closed unexpectedly?

Question

5.00/5 (1 vote)

See more:

Hello guys.
I have created a Win32 server-client application, where many clients connect to server, send query and recv response. It works fine in many installations, But the connection is closed in some others. Both client and server report that the connection is closed by the remote host. The sequence of socket operations after the connection is created is this:
Client: sends query Q1 (by calling send)
Server: recvs query Q1 and sends R1
Client: recvs R1
Client: sends query Q2
Server: recvs query Q2 and sends R2
Client: recvs R2
and so on
In some networks, after a period of time, for example, 1 hour or 10 minutes,
Client Sends Q(n) successfully
Server recvs SOCKET_ERROR. (WSA error 10054) and my code exits thread, deleting client. //unexpected
Client recvs SOCKET_ERROR. (WSA error 10054)
Both server and clients are alive and log all activities, Including WSAGetLastError results
In server there is one thread for each client. server has negligible delay before responding.
Why the function recv() at server returns SOCKET_ERROR? Who closes the socket? any links or suggestions appreciated.
mr.abzadeh

Posted 29-Nov-15 23:38pm

mr.abzadeh

Updated 30-Nov-15 1:04am

v2

Add a Solution

Comments

Richard MacCutchan 30-Nov-15 5:43am

You need to do some debugging to find out what is happening in the server.

Jochen Arndt 30-Nov-15 8:05am

Are there long delays between sending packets (does the error occur after there was a longer time without activity on the connection)?

If so, the connection may be closed by other components that are involved in the communication (routers, firewalls).

mr.abzadeh 30-Nov-15 8:44am

No, delays are less than 1 second.

Jochen Arndt 1-Dec-15 3:18am

You should use the Reply button right of a comment to answer (like I have done here). Than the author of the first comment gets an email notification. Now I saw your comment only be revisiting.

The problem may be still outside your application. Some network related components (the above and the OS) have time limits for connections even when there is traffic. This would be indicated when you always have the same time for a specific client.

You should investigate which clients have the problem and sort them by the time. Then compare the routing of those.

mr.abzadeh 3-Dec-15 1:31am

Thanks for your guide. I didn't know that. The problem occurs for all clients randomly. I agree that the problem is outside my server-application. But how can I identify that? Is there a reliable socket monitor that monitors the closing sockets and the source and reason of closing, such as a hardware action or a process that does this?

Jochen Arndt 3-Dec-15 3:09am

If it occurs for all clients I would connect a client as close as possible to the server (maybe on a second network interface) or at the next switch. If the closing still occurs you know that it must be your server or the switch if connected there.

Then you may capture the network traffic on the server interface and analyse. But this requires some experience and is time consuming because you have to filter out the relevant packets.

George Jonsson 1-Dec-15 3:21am

Do the clients keep the connection open during the whole life of the client app?

mr.abzadeh 3-Dec-15 1:24am

Yes. clients keep the connection until user decides to exit, or a SOCKET_ERROR is received.

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

icmtop · Answer 1 · 2015-11-30T21:11:00

That can be caused by TCP/IP communication problems.
I have been developed such programs a long ago, experienced such that.
You might use several threads to listen/send response/request.
At that time, you must check if request has correctly arrived in remote host from sender.
Of course, in TCP/IP communication as aside of UDP one, packets must be checked if they were arrived correctly without signal loss to remote host, but in reality due my view-points, some packets are lossed while traveling over internet.
You can check packet lossless state by using following methods.
1. A sends request R to B. A is sender, B is remote host.
2. If B receives correctly R, sends OK to A.
3. If A did not received OK, sends R again after some time (ex:1sec) to B.

This algorithm seems to be difficult to make, but if you make logics correctly, that is great way to overcome TCP/IP communication's problems.

That's all. I wish my words will help you.

icmtop · Answer 2 · 2015-11-30T21:45:00

Solution 2

It's me, icmtop. I suggested one solution short time ago. But I have another solution.
You must check followings.

1. Received data is valid for your response-process modules.
2. Send 'ping' with some interval during client program's life-time and check if the connection is okay. You will probably create socket and bind it with remote host on execution time of the program. If the connection is lost with some reasons(these reasons are almost due to server side), you will get exceptions. So you must check if the connection is okay. Many other programs such as Skype or linphone use "Ping" packed sending method to check if the connections are alive, if lost in connection, log in or re-create-bind socket to remote host.

I wish my words will help you.

Posted 30-Nov-15 21:45pm

icmtop

Comments

George Jonsson 1-Dec-15 3:48am

If you have an update, just update your existing solution.

icmtop 2-Dec-15 3:40am

Ah, I said that almost of connection loss problems will be occured due to server side.
Sorry, it can be occured due to client side, too.
For example, when client's network connection is disabled, or when client's network communication state is busy or bad, such that problems can be occured.
In a word, to build robust internet communication system, all the connections must be checked even though TCP supports packet-lossless-checking. Sometimes when network is bad or busy, TCP is not responsible for it's all tasks. And to be real programmer who processes all the exceptions, all the cases must be checked within his modules.
In this, ping method is excellent.
I suggested about ping method in my solution 2.
If error occurs even though implementing ping method, send comment again to discuss with me.
I am very interested and skilled in internet communication programming such as linphone i.e VoIP including screen sharing, audio conference.

George Jonsson · Answer 3 · 2015-12-02T19:42:00

Solution 3

I would suggest that you try to use transaction based connections instead of sessions based, that means that the client
1. opens a connection
2. sends its request
3. gets the response from the server
4. closes the connection

This way don't keep the connection open the whole time and the server can also serve more clients.

If this is a feasible way or not for you depends on your control of the software and how the communication behaviour of the clients looks like.

Posted 2-Dec-15 19:42pm

George Jonsson

Comments

mr.abzadeh 4-Dec-15 10:46am

It's a good idea. I'll add this as an option to my clients. But I think this is useful is smaller networks because the time cost of creating a thread in server for each transaction is too much.

mr.abzadeh 4-Dec-15 10:49am

It's a good idea. I'll add this as an option to my clients. But I think this is useful in smaller networks because the time cost of creating a thread in server for each transaction is too much.

Why the TCP server socket is closed unexpectedly?

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

Existing Members

...or Join us