Printable View
Hello.
I have a question, i made a tcp/ip application using the .NET TcpListener class, my problem is that sometimes (about 30 / 4000) the connection between the client and the server got interrupted in the middle and the server response to the client is lost.
is there a way to know if the server response was successfully sent to the client without the client response back?
Thanks,
Motil.
Surely if the client does not respond back then you know that it was not successfully received and can try send it again? or are you saying you dont want the client to have to send a response back at all after it receives the server response?
I would have thought you would get an exception thrown on the server side if you tried to send data and the connection got killed half way through, is that not happening?
Binary Serialization will help you out, but other than that, you should probably setup a Pinging system to make sure a connection is always established.
Best way to do this is add a checksum to the data and check this at the client and send a acknowledge if it is correct. If no ack is recieved, resend it
Hi chris, the client is not suppose to send back an answer to the server, if it does it was easy for me to detect whether he got the the response or not.Quote:
Originally Posted by chris128
the server does throw exceptions that i never understood what they are but its hard for me to detect if they related to this problem since we have more the 10,000 connection during the day, here is an example of those exception:
@formlesstree4 what exactly is Binary Serialization and how i can use it to understand my problem better?Code:10:13:07;ERROR :System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
Thanks for the replies.
Moti
That exception that you posted is exactly what I would expect to see when the connection between the server and client is disrupted. Basically if that exception is thrown whilst you are trying to send data then that means the data more than likely did not all get to the client, so send it again. The client should ideally have a method of determining if it has already received something though, so that it does not process the same data twice (not sure if that would matter to your app or not).
Hi chris thank you for the reply,
I do think this exception related to the problem but i have reasons to believe that the problem is internal (something with my application) because i started to see it back when i just testing the application locally
mostly (if not always) it happened when i fired a lot of requests at once... the problem is that i never had an idea how to debug it.. can you think of where it could happen? or any hints/leads i can try to solve it ?
Hard to say without seeing your code, but I'm guessing posting the relevant parts from the client and server might not be possible or might be too long and hard to follow, but post whatever you can and I'll see if there is anything I can spot (I'm no expert though). Are you using multiple threads to send/receive data on the client or server (or both)
i don't have to code here it in my office computer. but yea every client is in its own thread.
That would be my first suspicion then, that somewhere the synchronization between threads is not being handled properly. I'll be honest though I'm not sure what should be ok and what shouldnt be ok when talking about writing to TCP streams from different threads... Do you ever have more than one thread talking to the same client?