Что может вызвать спонтанную ошибку EPIPE без любого конца, звонящего близко () или катастрофический отказ?

У меня есть приложение, которое состоит из двух процессов (давайте назовем их A и B), подключенный друг к другу через сокеты домена Unix. Большую часть времени это хорошо работает, но некоторые пользователи сообщают о следующем поведении:

  1. Отправление запроса к B. Это работает. Теперь начинает читать ответ из B.
  2. B отправляет ответ на A. Соответствующая запись () вызов возвращает ошибку EPIPE, и в результате B близко () сокет. Однако A не закрыл () сокет, и при этом он не отказывал.
  3. Чтение A () вызов возвращается 0, указывая на конец файла. Думание, что B преждевременно закрыл соединение.

Пользователи также сообщили об изменениях этого поведения, например:

  1. Отправление запроса к B. Это работает частично, но прежде чем весь запрос отправлен запись A (), вызов возвращает EPIPE и в результате завершение () сокет. Однако B не закрыл () сокет, и при этом он не отказывал.
  2. B читает частичный запрос и затем внезапно получает EOF.

Проблема, я не могу воспроизвести это поведение локально вообще. Я попробовал OS X и Linux. Пользователи находятся на множестве систем, главным образом OS X и Linux.

Вещи, которые я уже попробовал и рассмотрел:

  • Двойное завершение () ошибки (близко () назван дважды на том же дескрипторе файла): вероятно, не, поскольку это привело бы к ошибкам EBADF, но я не видел их.
  • Увеличение максимального предела дескриптора файла. Один пользователь сообщил, что это работало на него, остальные сообщили, что это не сделало.

Что еще может возможно вызвать поведение как это? Я знаю наверняка, что ни A, ни B близко () сокет преждевременно, и знаю наверняка, что ни один из них не отказал, потому что и A и B смогли сообщить об ошибке. Это - как будто ядро внезапно решило отключить от сокета по некоторым причинам.

6
задан Hongli 10 February 2010 в 14:01
поделиться

3 ответа

Возможно, вы могли бы попробовать strace, как описано в: http://modperlbook.org/html /6-9-1-Detecting-Aborted-Connections.html

Я предполагаю, что ваша проблема связана с проблемой, описанной здесь: http://blog.netherlabs.nl/articles/2009/01/18 / the-ultimate-so_linger-page-or-why-is-my-tcp-not-надежный

К сожалению, у меня сама аналогичная проблема , но я не могу решить ее с помощью данные советы. Однако, возможно, эта вещь SO_LINGER сработает для вас.

4
ответ дан 17 December 2019 в 02:28
поделиться
  • shutdown () могла быть вызвана на одной из конечных точек сокета .

  • Если какая-либо из сторон может выполнить ответвление и выполнить дочерний процесс , убедитесь, что флаг FD_CLOEXEC (закрытие при выполнении) установлен на {{1} } дескриптор файла сокета, если вы не намеревались унаследовать его от дочернего элемента . В противном случае дочерний процесс может (случайно или иначе) манипулировать вашим соединением с сокетом.

2
ответ дан 17 December 2019 в 02:28
поделиться

Я бы также проверил, что посередине нет скрытого брандмауэра. Возможно, промежуточный узел пересылки на маршруте отправляет RST . Лучший способ отследить это, конечно, сниффер пакетов (или его кузен GUI .)

0
ответ дан 17 December 2019 в 02:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: