Тайм-аут получения TCP-сокета в солярисе после правильной работы в течение нескольких дней [8 - 15 дней] Почему? - PullRequest
Новая
       25

Тайм-аут получения TCP-сокета в солярисе после правильной работы в течение нескольких дней [8 - 15 дней] Почему?

0 голосов
/ 25 ноября 2011

Мы внедрили клиентское приложение SFTP на C, платформу Solaris. Приложение работает отлично в течение нескольких дней, после этого операция сокета [recv] завершается неудачно с тайм-аутом мы устанавливаем тайм-аут 120 секунд [2 минуты].

После перезапуска процесса все работает нормально.

Я хочу знать это:

  1. Как проверить причину ошибки TCP? errno приходит как 150 / ошибка тайм-аута
  2. Где найти причину ошибки TCP из файла системного журнала? в солярисе машина
  3. Пожалуйста, предоставьте некоторые предложения, чтобы я мог найти причину этой проблемы.

Ответы [ 2 ]

0 голосов
/ 26 ноября 2011

Насколько я понимаю, в Solaris errno 150 ссылается на EINPROGRESS, который может быть установлен вызовом connect().

Я не уверен, что recv() может установить для errno значение EINPROGRESS, по крайней мере, в Linux это не так.Таким образом, вы можете оказаться на неверном следе, глядя на recv().

. В любом случае, если для errno установлено значение EINPROGRESS на connect(), это не обязательно указывает на ошибку, но как-то ненормальное поведение процессасоединение с точки зрения того, чтобы быть медленнее, чем ожидалось.

См. Справочную страницу connect() для получения подробной информации о том, как справляться с такими ситуациями.

Поскольку справочная страница Linux для connect () действительно говорит нам гораздо больше, чем страница Solaris, которую я настоящим цитируюпервое:

EINPROGRESS Разъем неблокируемый, и соединение не может быть установлено немедленно.Можно выбрать (2) или опрос (2) для завершения, выбрав сокет для записи.После того, как select (2) указывает на возможность записи, используйте getsockopt (2), чтобы прочитать параметр SO_ERROR на уровне SOL_SOCKET, чтобы определить, успешно ли завершено connect () (SO_ERROR равен нулю) или неудачно (SO_ERROR является одним из обычных кодов ошибок, перечисленных здесь, объясняяпричина неудачи).

0 голосов
/ 25 ноября 2011

Вы тоже контролируете сервер? Работает ли сервер все время? Возможно, вы взаимодействуете с 2 или более серверами? Если «да» до последнего, ваш ARP-кэш мог содержать датированные записи, которые больше не соответствуют рабочему серверу. Если вы управляете серверами, попросите их при загрузке отправлять бесплатные ARP-запросы. Я не знаю, как именно это делается для соляриса, но это звучит как проблема ARP, которую вы можете отслеживать, скажем, с помощью tcpdump.

...