У меня довольно интересная проблема. У нас в работе 2 сети, которые являются физическими дубликатами друг друга (сеть A и сеть B). Они просто работают в разных подсетях.
Я работаю над некоторыми улучшениями отказоустойчивости для наших устройств, которые объединяются в сети друг с другом. Один из тестов, который я выполняю, - это поведение этих устройств при неправильной настройке. Например, допустим, у меня есть два устройства со следующими конфигурациями интерфейса:
Устройство X
IP: 10.200.234.127
Маска подсети: 255.255.254.0
Шлюз по умолчанию: 10.200.234.1
Устройство Y
IP: 10.200.234.127
Маска подсети: 255.255.254.0
Шлюз по умолчанию: 10.200.234.1
Эти 2 устройства обнаруживают друг друга посредством передачи пульса кластера. Контрольные сигналы содержат IP-адрес устройства и т. Д., Что позволяет им затем устанавливать связь друг с другом. Довольно стандартные вещи. Теперь допустим, что я ввел неверную конфигурацию сети, так что одно из этих устройств настроено на другой пакет солнечных лучей:
Устройство X
IP: 192.168.1.115
Маска подсети: 255.255.255.0
Шлюз по умолчанию: 192.168.1.1
Здесь происходит то, что оба устройства все еще узнают друг о друге из кластерных рассылок (они физически связаны друг с другом на одном коммутаторе). Однако, как и следовало ожидать, они не могут общаться друг с другом, как ожидалось. Тем не менее, я вижу странное поведение в отношении таймаутов подключения, когда эти устройства пытаются установить связь друг с другом. Например, если устройства подключены к сети A, соединение пытается выполнить тайм-аут в течение нескольких секунд, и это здорово. Теперь, если я помещаю оба устройства в сеть B, я вижу совершенно другое поведение. В сети B вызовы connect () для установления сокет-соединений между устройствами не быстро завершаются. Скорее, они попадают в этот цикл возврата и повторной передачи, который занимает 189 секунд, чтобы окончательно сдаться (повторные передачи через 3, 6, 12, 24, 48 и 96 секунд, как проверено с помощью wireshark).
Так что мне интересно, почему вызов connect () так быстро завершается неудачей в сети A, а не в сети B. Я попытался использовать блокирующие сокеты и вызов для connect (), а также неблокирующие сокеты и вызов connect () с последующим вызовом select (). В обоих случаях я не могу разорвать соединение раньше, чем через 189 секунд. Я знаю, что могу навязать более короткий тайм-аут в вызове, чтобы выбрать и сдаться гораздо раньше, но здесь дело не в этом. Я пытаюсь понять, что может отличаться в этих двух сетях, которые вызывают эту проблему.