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

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

Я работаю с коммерческим приложением, которое бросает SocketException с сообщением,

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

Это происходит при соединении сокетов между клиентом и сервером. Соединение живое и хорошее, и груды данных передаются, но затем он отключается из ниоткуда.

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

Любые комментарии/идеи приветствуются.

... Последние...

У меня есть некоторые записи из какой-либо трассировки .NET,

System.Net.Sockets Verbose: 0 : [8188] Socket#30180123::Send() DateTime=2010-04-07T20:49:48.6317500Z

System.Net.Sockets Error: 0 : [8188] Exception in the Socket#30180123::Send - An existing connection was forcibly closed by the remote host DateTime=2010-04-07T20:49:48.6317500Z 

System.Net.Sockets Verbose: 0 : [8188] Exiting Socket#30180123::Send() -> 0#0

На основании других частей журнала я видел, что он говорит, что "0 # 0" означает, что отправляется пакет длиной 0 байт. Но что это значит?

Одна из двух возможностей возникает, и я не уверен, что,

1) Соединение закрывается, но затем данные записываются в сокет, создавая таким образом исключение. 0 # 0 просто означает, что ничего не было отправлено, потому что сокет уже закрыт.

2) Соединение все еще открыто и отправляется пакет с нулевым байтом (т.е. код имеет ошибку), а 0 # 0 означает, что отправляется пакет с нулевыми байтами.

Что вы считаете? Возможно, это было неубедительно, но, возможно, кто-то еще видел такие вещи?

4b9b3361

ОТВЕТЫ

Ответ 1

Обычно это означает, что удаленная сторона закрыла соединение (обычно, отправляя пакет TCP/IP RST). Если вы работаете с сторонним приложением, вероятными причинами являются:

  • Вы отправляете неверные данные в приложение
  • По какой-то причине сетевая связь между клиентом и сервером снижается
  • Вы вызвали ошибку в стороннем приложении, вызвавшую ее сбой
  • Стороннее приложение исчерпало системные ресурсы

Вероятно, первый случай - это то, что происходит.

Вы можете запустить Wireshark, чтобы точно увидеть, что происходит на проводе, чтобы сузить проблему.

Без более конкретной информации маловероятно, чтобы кто-то здесь действительно мог вам очень помочь.

Ответ 2

Использование TLS 1.2 решило эту ошибку.
Вы можете заставить приложение использовать TLS 1.2 с этим (не забудьте выполнить его перед вызовом вашей службы):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Другое решение:
Включите сильную криптографию на своей локальной машине или сервере, чтобы использовать TLS1.2, потому что по умолчанию она отключена, поэтому используется только TLS1.0.
Чтобы включить сильную криптографию, выполните эти команды в PowerShell с правами администратора:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

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

Ответ 3

Это не ошибка в коде. Он исходит из реализации .Net Socket. Если вы используете перегруженную реализацию EndReceive, как показано ниже, вы не получите это исключение.

    SocketError errorCode;
    int nBytesRec = socket.EndReceive(ar, out errorCode);
    if (errorCode != SocketError.Success)
    {
        nBytesRec = 0;
    }

Ответ 4

Простое решение этой общей раздражающей проблемы:

Просто перейдите в свой файл .context.cs(расположенный под ".context.tt", который находится под вашим файлом "*.edmx" ).

Затем добавьте эту строку в свой конструктор:

public DBEntities() 
        : base("name=DBEntities") 
    { 
        this.Configuration.ProxyCreationEnabled = false; // ADD THIS LINE !
    }

надеюсь, что это полезно.

Ответ 5

Имел ту же ошибку. Фактически работал в случае, если трафик был отправлен с использованием некоторого прокси (скрипач в моем случае). Обновлена ​​.NET framework от 4.5.2 до >= 4.6, и теперь все работает нормально. Фактический запрос:
new WebClient().DownloadData("URL");
Исключением было:

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

Ответ 6

У меня есть это исключение из-за круговой ссылки в entity.In объект, который выглядит как

public class Catalog
{
    public int Id { get; set; }
    public int ParentId { get; set; }
    public Catalog Parent { get; set; }
    public ICollection<Catalog> ChildCatalogs { get; set; }
}

Я добавил [IgnoreDataMemberAttribute] в свойство Parent. И это решило проблему.

Ответ 7

Я встретил это исключение, когда свойство DateTime класса не получает значение. Я просто сделаю его nullable DateTime и нашел решение.

public class PlanningBoardBO
    {
        ... Other Properties ...

        public DateTime? PickupDate { get; set; }

        ... Here changed DateTime to DateTime?
    }

Ответ 8

Если работает в службе .Net 4.5.2

Для меня проблема была усугублена, потому что вызов выполнялся в службе .Net 4.5.2. Я последовал предложению @willmaz, но получил новую ошибку.

При запуске службы с включенным ведением журнала я видел, что рукопожатие с целевым сайтом инициируется нормально (и отправляется токен на предъявителя), но на следующем шаге для обработки вызова Post, кажется, будет сброшен токен аутентификации, и сайт будет ответить с Unauthorized.

Оказалось, что учетные данные пула служб не имеют прав на изменение TLS (?), И когда я поместил свою локальную учетную запись администратора в пул, все заработало.

Ответ 9

У меня была та же проблема, и мне удалось ее решить в конце концов. В моем случае порт, на который клиент отправляет запрос, не имеет привязки SSL-сертификата. Поэтому я исправил проблему, привязав сертификат SSL к порту на стороне сервера. Как только это было сделано, это исключение исчезло.

Ответ 10

(͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) ( ͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ) ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) ) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) (͡ ° ͜ʖ ͡ °) да

Ответ 11

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

Ответ 12

Эта ошибка произошла в моем приложении с CIP-протоколом всякий раз, когда я не отправлял или не получал данные менее чем за 10 секунд.

Это было вызвано использованием метода прямого открытия. Вы можете избежать этого, работая с другим методом или установить скорость обновления менее 10, которые поддерживают ваше прямое открытие.