0

I have two software components working in tandem - a Visual Studio C# chat application I made, which connects via a TCP NetworkStream to a Node.js application which is hosting a very simple TCP server.

The C# application sends messages via the TCP NetworkStream to the server, and everything works well, until I close the application (the actual process is relatively unimportant, but I've listed it here and included a short gif for clarity):

  • First, I start up the Node.js TCP server

  • Then the C# Application starts and opens up a TCP NetworkStream to the Node.js server

  • I type the message 'Hello!' into the C# app's input and hit 'Send'

  • The message is recieved by the TCP server

  • However when I close my C# application, I get an ECONNRESET error

enter image description here

I'm closing the NetworkStream on the client side using NetworkStream.Close() which, as @RonBeyer pointed out, is ill-advised. According to MSDN it:

Closes the current stream and releases any resources (such as sockets and file handles) associated with the current stream. Instead of calling this method, ensure that the stream is properly disposed.

I assume this is done with the using keyword in C# (which I am pretty unfamiliar with, given my novice understanding of the language).

BUT I DIGRESS. What I know is that an ECONNRESET error is caused by an abrupt closure of the socket / stream. The peculiar thing is, disregarding the ECONNRESET error on the server allows the server to accept new connections seemingly unperturbed.

So my question is:

  • does ignoring the error even matter in this context? Are there any possible implications I'm not seeing here?
  • and if it does/there are, what problems is it causing under the surface (undisposed resources etc.)?

I say this because the function of the server (to accept new TCP connections) remains uninterrupted, so it seems to make no difference superficially. Any expertise on the subject would be really helpful.

Pastebin to my C# code

Thanks in advance!

jonny
  • 3,022
  • 1
  • 17
  • 30
  • How are you closing the connection on the client side? – Ron Beyer Aug 20 '15 at 11:58
  • @RonBeyer Using the `NetworkStream.Close()` method inside the `Form.FormClosing` event handler. Funny thing is, it only seems to fire (i.e. closes the connection without throwing an exception) if I haven't sent a message prior to closing the C# app. If I **have** sent a message prior to closing the C# app, like in the above pictures, I get the `ECONNRESET` error - as though it isn't registering the `Form.FormClosing` and by extension not firing the `client.Close()` method...which is weird, because it seems to register during debugging :( – jonny Aug 20 '15 at 13:07
  • From MSDN for the `NetworkStream.Close`: *"Closes the current stream and releases any resources (such as sockets and file handles) associated with the current stream. **Instead of calling this method, ensure that the stream is properly disposed**."* Without seeing code about how you have the event wired up, its hard to help diagnose that problem. – Ron Beyer Aug 20 '15 at 13:54
  • @RonBeyer [Pastebin](http://pastebin.com/C7tR0Nz0) of my C# Code – jonny Aug 20 '15 at 15:15
  • I'd be more interested in seeing the Node server code since that is really where you are having the problem. The server should be able to handle un-graceful disconnects. – HeadCode Aug 25 '15 at 05:22
  • @HeadCode The server *does* handle ungraceful disconnects, my question is whether ungraceful disconnects have any meaningful underlying implications on the function of my app / server – jonny Aug 25 '15 at 08:55

1 Answers1

1

I suggest reading this post and then deciding for yourself based on your own knowledge of your code whether or not it's OK to ignore the ECONNRESET. It sounds like your Node app may be trying to write to the closed connection (heartbeats being sent?). Proper closing of the connection from your C# app would probably take care of this, but I have no knowledge of C#.

You may have a problem if you get lots of users and if ECONNRESET causes the connection to go into TIME_WAIT. That will tie up the port for 1-2 minutes. You would use netstat on Linux to look for that but I'm sure there is an equivalent Windows app.

If you really want to get into the nitty gritty of socket communications I suggest the excellent Unix Network Programming, by Stevens.

Community
  • 1
  • 1
HeadCode
  • 2,770
  • 1
  • 14
  • 26