Неправильные ошибки сокета (10054) в приложении Windows
Я работаю над приложением Windows (Microsoft Visual C++ 2005), которое использует несколько процессов. работает на разных хостах в интрасети.
Процессы взаимодействуют друг с другом с помощью TCP/IP. В системе могут быть разные процессы на одном и том же хосте или на разных хостах (т. е. связь может осуществляться как в пределах одного хост или между разными хостами).
В настоящее время у нас есть ошибка, которая появляется нерегулярно. Связь вроде работает какое-то время, затем он перестает работать. Потом снова работает какое-то время.
Когда связь не работает, мы получаем ошибку (видимо, пока процесс пытался отправить данные). Вызов выглядит следующим образом:
send(socket, (char *) data, (int) data_size, 0);
Изучив код ошибки, который мы получаем от
WSAGetLastError()
, мы видим, что это ошибка 10054. Вот что я нашел в документации Microsoft. (см. здесь ):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
Итак, насколько я понимаю, соединение было прервано принимающим процессом. В некоторых случаях эта ошибка (AFAIK) верна: один процесс завершился и поэтому недоступен. В других случаях работают и отправитель, и получатель. и запись активности, но они не могут обмениваться данными из-за вышеуказанной ошибки (ошибка сообщается в журналах).
Мои вопросы.
- Что означает параметр SO_LINGER?
- Что такое активность поддержания активности и как она может разорвать соединение?
- Как можно избежать этой проблемы или избавиться от нее?
Относительно последнего вопроса. Первое решение, которое мы попробовали (на самом деле, это скорее временное решение) повторно отправлял сообщение при возникновении ошибки.К сожалению, одна и та же ошибка возникает снова и снова в течение некоторого времени (несколько минут). Так что это не решение.
На данный момент мы не понимаем, проблема в программном обеспечении или в конфигурации вопрос: может быть, мы должны проверить что-то в реестре Windows?
Одна из гипотез заключалась в том, что в ОС закончились эфемерные порты (в случае закрыты, но порты не освобождаются из-за TcpTimedWaitDelay), но анализируя этом выпуске мы думаем, что их должно быть много: проблема возникает даже если сообщения не отправляются слишком часто между процессами. Однако мы до сих пор не На 100% уверен, что мы можем это исключить: могут ли эфемерные порты как-то теряться (???)
Еще одна деталь, которая может помочь, это то, что отправка и получение происходит в каждом процессе одновременно в отдельных потоках: есть ли общие структуры данных в Библиотеки TCP/IP, которые могут быть повреждены?
Что еще очень странно, так это то, что проблема возникает нерегулярно: связь работает Несколько минут нормально, потом несколько минут не работает, потом снова работает.
Спасибо за любые идеи и предложения.
РЕДАКТИРОВАТЬ
Спасибо за подсказки, подтверждающие, что единственным возможным объяснением была ошибка закрытия соединения. Дальнейшим анализом проблемы мы выяснили, что серверный процесс соединения завис/был остановлен и перезапущен. Таким образом, был запущен новый серверный процесс и прослушивал правильный порт, но клиент не обнаружил этого и все еще пытался использовать старое соединение.Теперь у нас есть механизм обнаружения таких ситуаций и сброса соединения на стороне клиента.