contel
asked on
Client socket stops responding on client
Hi experts,
I'm developing a client server in MFC using VisualStudio 2010 IDE.
On the client side I'm using CSocket while on the server side I'm using CAsyncSocket.
When I run my client and server they seem to communicate fine at startup, but after a couple of hours the communication between the server to the client stops working.
After debugging the situation, I found out that the server keeps on getting WSAEWOULDBLOCK errors on the client socket, which means that the client socket is full. However on the client socket the CSocket::OnReceive() overrider method is not called.
I suspect the problem is somewhere in the implementation of the CSocket class.
My questions are:
1. Is this a known problem with CSocket?
2. Is there any workaround for the problem?
Many thanks,
Dudi.
I'm developing a client server in MFC using VisualStudio 2010 IDE.
On the client side I'm using CSocket while on the server side I'm using CAsyncSocket.
When I run my client and server they seem to communicate fine at startup, but after a couple of hours the communication between the server to the client stops working.
After debugging the situation, I found out that the server keeps on getting WSAEWOULDBLOCK errors on the client socket, which means that the client socket is full. However on the client socket the CSocket::OnReceive() overrider method is not called.
I suspect the problem is somewhere in the implementation of the CSocket class.
My questions are:
1. Is this a known problem with CSocket?
2. Is there any workaround for the problem?
Many thanks,
Dudi.
ASKER
Maybe, I was not so clear.
The problem is that the server does send messages to the client, I verified it with the debugger. But I get a SOCKET_ERROR as the return code after calling Send() in the server code and the GetLastError() returns WSAEWOULDBLOCK.
The problem is that the server does send messages to the client, I verified it with the debugger. But I get a SOCKET_ERROR as the return code after calling Send() in the server code and the GetLastError() returns WSAEWOULDBLOCK.
the GetLastError is only fitting to the last operation if that failed. if the Send returns without error the GetLastError is meaningless and would be from any read operation on the same or other sockets.
i never experienced a WSAEWOULDBLOCK from a send operation cause that would only occur if the tcp/ip was down.
if the Send returns without error but could not received from client you should check whether the target address is still valid and whether the message length really is greater 0.
on the client side you might check whether the connection is still valid for example by calling IsBlocking member function which should return error if something is wrong. you also could actively call the Receive function though that should block (you could put the call into a thread function therefore). for both calls the GetLastError should show the real problem.
Sara
i never experienced a WSAEWOULDBLOCK from a send operation cause that would only occur if the tcp/ip was down.
if the Send returns without error but could not received from client you should check whether the target address is still valid and whether the message length really is greater 0.
on the client side you might check whether the connection is still valid for example by calling IsBlocking member function which should return error if something is wrong. you also could actively call the Receive function though that should block (you could put the call into a thread function therefore). for both calls the GetLastError should show the real problem.
Sara
ASKER
After getting deeper into the problem, I found out that that what seems to cause it, is a multithreading situation, where more than one thread is accessing the same client socket on the client side.
Due to the fact that CSocket is NOT thread safe (it doesn't help, even if you lock the access to it with critical section object). This may explain the weird behavior I am facing.
The client's code I'm dealing with is a legacy code and I had no idea at first that this was the case.
Anyway, I've changed the code so now only one thread (the main thread) is using the socket.
I will let you know if it fixed the problem:-)
Due to the fact that CSocket is NOT thread safe (it doesn't help, even if you lock the access to it with critical section object). This may explain the weird behavior I am facing.
The client's code I'm dealing with is a legacy code and I had no idea at first that this was the case.
Anyway, I've changed the code so now only one thread (the main thread) is using the socket.
I will let you know if it fixed the problem:-)
a socket is a stream and there is no (senseful) way to make a stream thread-safe. similar problems would arise if you would use the same file stream by different threads.
if multiple threads need to communicate with the server you either need to establish multiple connections or you have to establish a separate thread which handles all communications in a thread-safe way. the latter is the normal way to solve the issue.
Sara
if multiple threads need to communicate with the server you either need to establish multiple connections or you have to establish a separate thread which handles all communications in a thread-safe way. the latter is the normal way to solve the issue.
Sara
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I've requested that this question be closed as follows:
Accepted answer: 0 points for contel's comment #a37961761
for the following reason:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Accepted answer: 0 points for contel's comment #a37961761
for the following reason:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
i think my comment http:#a37945609 is the answer and the comment of the author (contel) is confirming it.
Sara
Sara
the WSAEWOULDBLOCK errors are normal for a socket that was set to non-blocking and a server which occassionally polls for client messages. normally those errors shouldn't be logged.
but for your issue it means that the server still has a valid connection to the client what is good. when the client doesn't receive messages then, it means the server doesn't send. that could be cause the server waits for some kind of 'i am alive' from client and would not go on without. Or simpler, there is nothing to send.
Sara