Обнаружение отключения TCP по ненадежной сети

Question

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

Установка выглядит следующим образом:

Узел A --- Узел реле --- Узел B

Одна проблема, с которой я постоянно сталкиваюсь, заключается в том, что каким-то образом соединение прерывается, и ни узел A, ни B не знают, что канал не работает, и все же продолжают передавать данные. Соединение TCP также не истекает. Я добавил сообщение, которое через некоторое время вызывает тайм-аут, но я все же хотел бы знать, что является основной причиной того, что TCP не делает тайм-аут.

Вот параметры, которые я включаю при настройке сокета:

channel.socket().setKeepAlive(false);
channel.socket().setTrafficClass(0x08); // for max throughput

Это поведение странное, поскольку оно полностью отличается от того, когда у меня есть проводная сеть. В проводной сети я могу смоделировать отключенное соединение, вытянув шнур Ethernet, однако, как только я снова подключу шнур, соединение будет восстановлено, и сообщения начнут проходить еще раз.

В радиосети соединение никогда не восстанавливается, и когда оно молча умирает, сообщения никогда не возобновляются.

Есть ли еще какие-то неизвестные java-установки или настройки для сокета, которые я могу использовать, кроме того, почему я вижу это поведение в первую очередь?

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

Answer 1

В 7-уровневой модели OSI первые два уровня - это физический канал и канал передачи данных.Ваше физическое оборудование, работающее по протоколу канала передачи данных в проводной сети Ethernet, может определить, когда кабель подключен.Ваше беспроводное оборудование и соответствующий протокол, вероятно, не так много.Стек TCP не может ничего сделать с таймаутом, если материал layer1 / 2 не сигнализирует о его отключении.

Answer 2

Протокол TCP был разработан, чтобы быть тихим.RFC требует сердцебиения с поддержкой активности не чаще, чем через 2 часа.Если у вас нет контроля над системой на обоих концах, чтобы изменить сердцебиение по умолчанию на 2 часа (иногда это требует перестройки ядра), вы должны добавить пульс в собственном приложении.

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

Вы получаете уведомление в локальной сети, потому что система может определить состояние соединения и сбросить все соединения в этой сети.

Кстати, вы хотите установить для Keepalive значение TRUE, а не false.С Keepalive вы, по крайней мере, получаете медленное сердцебиение.

Answer 3

Определить «никогда»?

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

См. Здесь: http://www.ietf.org/rfc/rfc2988.txt, здесь: http://msdn.microsoft.com/en-us/library/ms819737.aspx, и т. Д.

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