CODEWITHSUNDEEP
c#socketsnetwork-programmingwireshark
Imran Azad
Imran Azad

Reputation: 1048

Transport errors

I'm working on a crawler and my attempt at fixing an issue with this exception:

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.NetworkStream.BeginRead(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)

was to implement a retry pattern after using wireshark and looking at network logs I concluded that these errors are most likely transient.

However these exceptions are really bugging me now and I would really like to get to the bottom of why I am getting these errors. Can anyone suggest a good strategy to adopt and tools I can use or reasons you can think of why the connection is being forcibly closed?

Thanks

Upvotes: 0

Views: 868

Answers (2)

Michael Rätzel
Michael Rätzel

Reputation: 411

I see two questions here:

  • Why is the Exception being thrown?
  • Why is the connection being forcibly closed?

Why is the Exception being thrown?

This is a problem with the transport implementation you have chosen to consume. Apparently, microsoft decided to communicate the error by wrapping it up in an exception and throw it up the stack. The corresponding source code can be found here: http://referencesource.microsoft.com/#System/net/System/Net/Sockets/NetworkStream.cs,766
In the source code, you can also see that the InnerException is set and contains a localization independent representation of the errorCode.
The bottom line is that this exception being thrown does not mean anything exceptional happened, it can happen just because the connection was dropped.

Which brings us to the next question:

Why is the connection being forcibly closed?

Just as the exceptions message hints, the reason could well be the remote host. Therefore, looking at the remote hosts implementation could be required to get to the bottom of this. I suspect though, that just judging by the exception, you cannot rule out the reason to be somewhere in between the hosts (sharks have shown an appetite for fiber cables).
I suggest the following experiment:

  • Set up the two hosts residing on different machines and let them connect through a cable.
  • While the connection is established, unplug the cable.

This could not disproof but at least proof the possibility.

However, "working on a crawler" suggests that you might encounter a variety of different hosts and it is to be expected that some of them turn taciturn sometimes for whatever reason you would care to imagine.

EDIT: I remember catching this exception when using TCP over IP when the remote host sent a packet with the RST Flag set. The value of the RST Flag is displayed in Wireshark.

Upvotes: 1

Udontknow
Udontknow

Reputation: 1580

My 50 cents: This is the normal behaviour when using networkstreams for reading data from a socket. It is not a user error, the exception thrown just causes the data processing in the reading thread to be interrupted. Just wrap it up with a try/catch-handler accordingly.

You could try to use the DebuggerNonUserCode attribute (https://msdn.microsoft.com/de-de/library/system.diagnostics.debuggernonusercodeattribute%28v=vs.110%29.aspx) to suppress debugger alerts when an exception is triggered. Be aware that this may also "hide" other exceptions...

Upvotes: 0

Related Questions