Как определить максимальное время, необходимое для смерти сокета TCP из-за промежуточного отключения сети?

Question

У меня есть программа на C ++, использующая стандартный API-интерфейс сокетов, работающий в Ubuntu 7.04, который поддерживает открытый сокет для сервера. Моя система живет за роутером. Я хочу выяснить, сколько времени может занять получение ошибки сокета, как только моя программа начнет отправлять ПОСЛЕ того, как маршрутизатор отключен от сети.

То есть моя программа может бездействовать (в ожидании пользователя). Маршрутизатор отключен от Интернета, а затем моя программа пытается установить связь через этот сокет.

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

Мне нужно установить какое-то время «наихудшего случая», которое я могу дать группе QA (и клиенту), чтобы они могли проверить, что мой код переходит в надлежащее автономное состояние.

(для справки, моя программа является частью системы оплаты за насос для заправочных станций, а сервер - это система, которая разрешает платежные транзакции. Станция может быть полностью отключена от сети по разным причинам. и клиент просто хочет знать, чего ожидать).

РЕДАКТИРОВАТЬ: Я не был ясен. Там нет человека, ожидающего этой вещи, это просто для бэк-офиса нотации системы в автономном режиме. Когда аутентификация не возвращается через 30 секунд, транзакция заканчивается, и люди уходят, чтобы заняться другими делами.

РЕДАКТИРОВАТЬ: Я пришел к выводу, что вопрос в действительности не отвечает в общем случае. Количество факторов, участвующих в определении того, сколько времени требуется TCP-соединению для устранения ошибки из-за сбоя в нисходящем направлении, слишком зависит от точного оборудования и сбоя, чтобы не было простого ответа.

Answer 1

Вы должны быть в состоянии использовать:

http://linux.die.net/man/2/getsockopt

с:

SO_RCVTIMEO и SO_SNDTIMEO

для определения времени ожидания.

Эта ссылка: http://linux.die.net/man/7/socket

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

По моему опыту, просто выбрать время, как правило, плохая идея. Даже когда это звучит разумно, произвольные тайм-ауты обычно ведут себя неправильно на практике. Общий результат заключается в том, что приложение становится непригодным для использования, когда среда выходит за рамки нормы.

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

Answer 2

Я думаю, что лучший подход - не пытаться определить используемый тайм-аут, а фактически указать его самостоятельно.

В зависимости от вашей ОС вы можете: -

• использовать setsockopt () с опцией SO_SNDTIMEO,
• используйте неблокирующую функцию send (), а затем используйте select () с таймаутом
• используйте неблокирующую функцию send () и время ожидания получения ожидаемых данных.

Answer 3

Я бы обернул вопрос по-другому: как долго оператор «до» готов стоять там, выглядя глупо перед клиентом, прежде чем они скажут, что он не должен работать, позволяет это делать вручную.

Поэтому выберите время, например, 1 минуту (при условии, что ваша сеть не отключается автоматически и, таким образом, будет повторно подключаться при возникновении трафика)

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

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

В противном случае, в зависимости от вашего IP-стека, тайм-аут в худшем случае может быть «никогда не истекает».