Тайм-аут соединения TCP составляет 20 или 21 секунду на * некоторых * ПК при установке на 500 мс

Мне дали 10 новых ПК, все (предположительно) с Windows 7 Pro, недавно установленными и ничего не сделанное с ними.

У меня есть программа, закодированная в Delphi XE2, с использованием компонентов Indy 10 для сети. Я установил свойства "Время ожидания подключения" и "Тайм-аут" для моего TIdTcpCleint до 500 мс, установил "розетка розлива" в "зависимый от o/s" (я также попробовал построить с ним значение "Нет" ) и оставить "использовать Nagle", (независимо от того, что установлено в True (я также пытался с ложным).

Здесь проблема: когда я запускаю тот же .EXE на этих ПК и тестирую случай, когда я вытаскиваю сетевой кабель, моя трассировка отладки показывает, что тайм-аут попытки подключения/подключения происходит в течение той же секунды или следующей секунды (с гранулярность 1 секунда), но в других случаях это 20 или 21 секунда, прежде чем я увижу тайм-аут конденсации.

Казалось бы, некоторые из них не являются полностью "свежими", как утверждают, ПК, хотя я не вижу установленных aps. Возможно, кто-то установил somethign, а затем удалил его, возможно, они попытались настроить производительность.

Прежде чем переустанавливать Windows на 10 ПК, может ли кто-нибудь предложить, где искать? 20 (или 21) секунды звонят в колокольчик в отношении тайм-аута подключения TCP-клиента?

[обновление] Я пытаюсь подключиться непосредственно к определенному IP-адресу, поэтому я не уверен, что предложение @Nikolai для проверки DNS имеет значение. Извините, что не упоминал об этом изначально.

[upperdate] программа не пытается открыть сокет. Он соединяет, отправляет некоторые данные и разъединяет - многократно, для каждой новой части данных.

Ответ 1

К сожалению, это работает по назначению. Соединитель уже отключился. Indy определил, что соединение будет терпеть неудачу в 500 миллисекундах, которые вы попросили. Однако это не гарантирует возврата функции.

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

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

Что касается того, почему это происходит немедленно на некоторых системах, и в течение 20 секунд на других, это зависит от точной конфигурации сети. Например, если IPv6 включен, стек может попытаться использовать соединение IPv6-to-IPv4, и это может не сообщаться, даже если физический интерфейс не работает. Немедленное обнаружение невозможности соединения никогда не гарантируется, и вы не должны полагаться на него.

Ответ 2

У меня были те же проблемы с INDY в прошлом (при использовании D6, 1998-2000). Я изменил компонент на IP * Works. В то время это был внешний компонент, но, насколько я знаю, он включен в XE2. Ip * Works немного сложно понять в начале, но способ, которым они подходят к структуре связи, очень отличается.

Я думаю, что было бы полезно попробовать.