There is a simple synchronous TCP client-server "request-response", written in a hurry, but, as I thought, quite reliable - there is also the processing of Read () = 0, and all try-catch'and Connect, Read and Write , and even on AcceptTcpClient.
Weeks 2 server worked fine, although clients are mobile, and there are especially frequent network problems.
But here on Disconnect, which is called by the server already in catch (in each catch), there was no try-catch. And even there was no logging after each Disconnect - because of what I now cannot understand whether Disconnect has a problem, or it is already after that, when the cycle goes to a new Accept. (The process is already completed - do not offer procdump)
Literally, the code on the server to return the answer looked like this:
try { client.GetStream().Write(msResp.ToArray(), 0, (int)msResp.Length); } catch (Exception ex) { log(cip + "ERROR: Cannot write response"); log(ex); client.Client.Disconnect(true); //TODO try-catch continue; //уходим на accept нового } Try-catch only TODO :)
Previously, all the errors were of a timeout type (the server has a hard ReceiveTimeout for each client), and they were not in Write, but in Read, and although there was also no try-catch on Disconnect, everything was fine.
But today a session appeared in the log with an error like "operation is not possible for unconnected sockets" on Write, the server has been regularly pledged this error ... and fell. Hence the conclusion that Disconnect itself in this case is also needed in try-catch.
But MSDN documentation does not contain a clear answer to such a question, and there is no time to check it yourself.
