An existing connection was forcibly closed by the remote host

I have a fat VB.NET Winform client that is using the an old asmx style web service. Very often, when I perform query that takes a while or pass a large amt of data to a web service in a dataset, I get the subject error.

The error seems to occur in < 1 min, which is far less than the web service timeout value that I have set or the timeout value on the ADO Command object that is performing the query within the web server.

It seems to occur whenever I am performing a large query that expects to return a lot of rows or when I am sending up a large amount of data to the web service. For example, it just occurred when I was passing a large dataset to the web server:

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> 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)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.H开发者_如何学PythonttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Smit.Pipeline.Bo.localhost.WsSR.SaveOptions(String emailId, DataSet dsNeighborhood, DataSet dsOption, DataSet dsTaskApplications, DataSet dsCcUsers, DataSet dsDistinctUsers, DataSet dsReferencedApplications) in C:\My\Code\Pipeline2\Smit.Pipeline.Bo\Web References\localhost\Reference.vb:line 944
   at Smit.Pipeline.Bo.Options.Save(TaskApplications updatedTaskApplications) in 

I've been looking a tons of postings on this error and it is surprising at how varied the circumstances which cause this error are. I've tried messing with Wireshark, but I am clueless how to use it.

This application only has about 20 users at any one time and I am able to reproduce this error in the middle of the night when probably no one is using the app, so I don't think that the number of requests to the web server or to the database is high. I'm probably the only person using the app right now and I just got the error now. It seems to have to do everything with the amt of data being passed in either direction.

This error is really chronic and killing me. Please help.

Check your client's app.config binding setting and see if you have specified a Max message size. The default value for this is 65536

To change this, either put it in your binding configuration (maxReceivedMessageSize, maxBufferSize and maxArrayLength are key properties for this) in your app.config, or programmatically by changing the property on the binding, like so

System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding();

// if you are getting a LOT of data back, you will need to up Message Size
binding.MaxReceivedMessageSize = int.MaxValue; 

If this doesnt solve your issue, you will have to check the server side's event log for details. The message means that the client didnt expect the connection to close, but it did, and it could mean many different things.

If possible, use WCF for web services. It solves a lot of problems that ASMX services still suffer from.

To increase the server side transmission limit and execution timeout, use this

<configuration>
  <system.web> 
    <httpRuntime maxMessageLength="409600" executionTimeoutInSeconds="300"/> 
  </system.web>
</configuration> 

I was having the exact same issue. Web service calls would fail with the same intermittent exception (~ once a day). It wasn't related to too large packet sizes or too small timeouts.

I ended up just putting in some retry logic which has worked around the problem. See: How can I improve this exception retry scenario?

This code solved the issue for me:

Socket.ReceiveFrom(Buffer, Net.Sockets.SocketFlags.None, ReceiveEndpoint)
Socket.SendTo(Buffer, Length, Net.Sockets.SocketFlags.None, ReceiveEndpoint)

When I used the function with socketsflags the server/client didn't get disconnected again.

If it is ASP.NET try setting the maxRequestLength to a higher value in the web.config file

<httpRuntime maxRequestLength="65536"/>

Do not increase the value too much as it might result in other errors like Access Denial etc. If it is a dataupload to a remote server, try slicing the data and sending in chunks.

Kind Regards,

Mafaz

In my case, my generic HTTP handler (handler.ashx) was experiencing the unexpectedly dropped connection when trying to retrieve large files from a WCF service. In the end, the answer came in one Microsoft web page (https://msdn.microsoft.com/en-us/library/ms733742.aspx) and a call to Microsoft, who told me that one critical item on that page was misspelled (should have been "Streamed" instead of "Streaming"). The corrected code snippet from that page, applied to my WCF service's app.config file is this:

<system.serviceModel>
<bindings>
    ...
    <basicHttpBinding>
    <binding name="ExampleBinding" transferMode="Streamed"/>
        </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

The key was to set the transfer mode.

try this ,it work for me for 10000 sent via network stream

defind SendBufferSize more than setting of the current TcpClient or optimize to your system if not define the value is 8192 that mean you can not send byte out more than this.

**YourInstantTcpClient**.SendBufferSize = 6550000

Sorry ,i'm thai people,may my english isn't good.

For IIS 7 (in my case), the webservice's application pool's identity was "ApplicationPoolIdentity". I assigned to a local user and it worked just fine.

Okay, i got same error. But in my case the problem was in AV software, which was blocking reporting services locally.