vb.net 现有连接被远程主机强行关闭
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2862817/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
An existing connection was forcibly closed by the remote host
提问by Chad
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.
我有一个胖 VB.NET Winform 客户端，它使用旧的 asmx 样式 Web 服务。很多时候，当我执行需要一段时间的查询或将大量数据传递给数据集中的 Web 服务时，我会收到主题错误。
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.
该错误似乎发生在 < 1 分钟内，这远小于我设置的 Web 服务超时值或在 Web 服务器内执行查询的 ADO 命令对象上的超时值。
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:
每当我执行希望返回大量行的大型查询时，或者当我向 Web 服务发送大量数据时，似乎都会发生这种情况。例如，当我将一个大数据集传递给 Web 服务器时，它就发生了：
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.HttpWebClientProtocol.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.
我一直在查看有关此错误的大量帖子，令人惊讶的是导致此错误的情况多种多样。我试过弄乱 Wireshark，但我不知道如何使用它。
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.
这个应用程序在任何时候只有大约 20 个用户，我能够在半夜重现这个错误，当时可能没有人使用这个应用程序，所以我不认为对 Web 服务器的请求数量或到数据库高。我可能是现在唯一使用该应用程序的人，但我现在刚刚收到错误消息。它似乎必须处理向任一方向传递的大量数据。
This error is really chronic and killing me. Please help.
这个错误真的是慢性的，让我丧命。请帮忙。
回答by Greg Olmstead
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
检查您客户端的 app.config 绑定设置，看看您是否指定了最大消息大小。默认值为 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
要更改此设置，请将其放在 app.config 中的绑定配置中（maxReceivedMessageSize、maxBufferSize 和 maxArrayLength 是此的关键属性），或者通过更改绑定上的属性以编程方式，如下所示
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.
如果可能，请将 WCF 用于 Web 服务。它解决了很多 ASMX 服务仍然存在的问题。
To increase the server side transmission limit and execution timeout, use this
要增加服务器端传输限制和执行超时，请使用此
<configuration>
<system.web>
<httpRuntime maxMessageLength="409600" executionTimeoutInSeconds="300"/>
</system.web>
</configuration>
回答by robbie
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.
我遇到了完全相同的问题。Web 服务调用会因相同的间歇性异常而失败（大约每天一次）。它与太大的数据包大小或太小的超时无关。
I ended up just putting in some retry logic which has worked around the problem. See: How can I improve this exception retry scenario?
我最终只是放入了一些解决了这个问题的重试逻辑。请参阅：如何改进此异常重试方案？
回答by Frank Jansen of Lorkeers
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 socketsflagsthe server/client didn't get disconnected again.
当我将该功能与socketsflags服务器/客户端一起使用时，没有再次断开连接。
回答by sm2mafaz
If it is ASP.NET try setting the maxRequestLength to a higher value in the web.config file
如果是 ASP.NET，请尝试在 web.config 文件中将 maxRequestLength 设置为更高的值
<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
马法兹
回答by Paul H. Harder II
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:
就我而言，我的通用 HTTP 处理程序 (handler.ashx) 在尝试从 WCF 服务检索大文件时遇到意外断开的连接。最后，答案出现在一个 Microsoft 网页 ( https://msdn.microsoft.com/en-us/library/ms733742.aspx) 和给 Microsoft 的电话中，他告诉我该页面上的一个关键项目是拼写错误（应该是“Streamed”而不是“Streaming”）。该页面中更正后的代码片段，应用于我的 WCF 服务的 app.config 文件是这样的：
<system.serviceModel>
<bindings>
...
<basicHttpBinding>
<binding name="ExampleBinding" transferMode="Streamed"/>
</basicHttpBinding>
</bindings>
...
<system.serviceModel>
The key was to set the transfer mode.
关键是设置传输模式。
回答by user007
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.
对于 IIS 7（就我而言），Web 服务的应用程序池的标识是“ApplicationPoolIdentity”。我分配给了一个本地用户，它工作得很好。
回答by Andrew Kostenko
Okay, i got same error. But in my case the problem was in AV software, which was blocking reporting services locally.
好的，我遇到了同样的错误。但就我而言，问题出在 AV 软件中，该软件在本地阻止了报告服务。
回答by mezz
try this ,it work for me for 10000 sent via network stream
试试这个，它适用于我通过网络流发送的 10000
defind SendBufferSizemore 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.
defind SendBufferSize超过目前的TcpClient或优化的设置为你的系统，如果没有定义的值是8192这意味着你可以不发送字节出莫过于此。
**YourInstantTcpClient**.SendBufferSize = 6550000
**YourInstantTcpClient**.SendBufferSize = 6550000
Sorry ,i'm thai people,may my english isn't good.
对不起，我是泰国人，可能我的英语不好。
