Существующее соединение было принудительно закрыто удаленным хостом

Question

У меня есть жирный клиент Winform VB.NET, который использует старый веб-сервис asmx. Очень часто, когда я выполняю запрос, который занимает некоторое время или передает большой объем данных веб-службе в наборе данных, я получаю предметную ошибку.

Ошибка возникает в < 1 мин., Что намного меньше значения тайм-аута веб-службы, которое я установил, или значения таймаута для объекта команды ADO, выполняющего запрос на веб-сервере.

Кажется, что возникает, когда я выполняю большой запрос, который ожидает возврата большого количества строк или когда я отправляю большой объем данных в веб-службу. Например, только что произошло, когда я проходил большой набор данных на веб-сервере:

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 

Я выглядя тонны проводок на эту ошибку, и это удивительно, как разнообразны обстоятельства, которые вызывают эту ошибку находятся. Я пробовал общаться с Wireshark, но я не знаю, как его использовать.

Это приложение имеет только около 20 пользователей в любое время, и я могу воспроизвести эту ошибку посреди ночи, когда, вероятно, никто не использует приложение, поэтому я не думаю, что количество запросов на веб-сервер или база данных высока. Я, вероятно, единственный человек, который сейчас использует приложение, и сейчас я получил ошибку. Кажется, что он должен делать все с передачей данных в любом направлении.

Эта ошибка действительно хроническая и убивает меня. Пожалуйста помоги.

Answer 1

Проверьте настройку привязки вашего приложения app.config и посмотрите, указали ли вы максимальный размер сообщения. Значением по умолчанию для этого является 65536

Чтобы изменить это, поместите его в свою конфигурацию привязки (maxReceivedMessageSize, maxBufferSize и maxArrayLength являются ключевыми свойствами для этого) в вашем app.config или программно, изменив свойство на привязку, например,

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; 

Если это не поможет решить проблему, вам необходимо будет проверить журнал событий на стороне сервера. Сообщение означает, что клиент не ожидал закрытия соединения, но это произошло, и это может означать много разных вещей.

Если возможно, используйте WCF для веб-сервисов. Он решает множество проблем, с которыми по-прежнему страдают службы ASMX.

Для увеличения лимита на стороне сервера передачи и тайм-аута выполнения, используйте этот

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

Answer 2

у меня был точно такой же вопрос. Вызов веб-службы завершился с таким же прерывистым исключением (~ один раз в день). Это не было связано со слишком большими размерами пакетов или слишком малыми таймаутами.

Я закончил тем, что просто применил логику повтора, которая обошла проблему. См: How can I improve this exception retry scenario?

Answer 3

попробовать это, это работает для меня 10000 отправлены через сетевой поток

оп ределяется SendBufferSize больше, чем установка текущего TcpClient или оптимизировать вашу систему , если не определить значение 8192, что означает, что вы не можете отправить байта больше, чем это.

** YourInstantTcpClient**.SendBufferSize = 6550000

К сожалению, я тайские людям, может мой английский не очень хорошо.

Answer 4

Этот код был решен вопрос для меня:

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

Когда я использовал функцию с socketsflags на сервер/клиент не получил отключен снова.

Answer 5

Если ASP.NET попробуйте установить maxRequestLength на более высокое значение в файле web.config

<httpRuntime maxRequestLength="65536"/> 

Не увеличивайте значение слишком много, поскольку это может привести к другим ошибкам, как Access Отрицание и т.д. Если это загрузка данных на удаленный сервер, попробуйте нарезать данные и отправить куски.

Уважением,

Mafaz

Answer 6

для IIS 7 (в моем случае), удостоверение пула приложений в WebService был в "ApplicationPoolIdentity". Я назначил локального пользователя, и он работал нормально.

Answer 7

Хорошо, у меня такая же ошибка. Но в моем случае проблема заключалась в программном обеспечении AV, которое локально блокировало службы отчетов.

Answer 8

В моем случае мой общий обработчик HTTP (handler.ashx) испытывал неожиданно отброшенное соединение при попытке получить большие файлы из службы WCF. В конце концов, ответ пришел на одной веб-странице Microsoft (https://msdn.microsoft.com/en-us/library/ms733742.aspx) и обратился к Microsoft, который сказал мне, что один критический элемент на этой странице был опечатан (должен был быть «потоковый», а не «потоковый»). Исправленный фрагмент кода с этой страницы, применяется к файлу app.config моей службы WCF заключается в следующем:

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

Ключ был установлен режим передачи.