Как ssh перед лицом огромных (25 секунд) задержек?

1721
WilliamKF

Мне нужно создать ssh-соединение между двумя Linux-машинами под управлением Centos v5, но задержка может достигать 25 секунд. Я обнаружил, что если я тестирую что-то, подходящее к этой конфигурации искусственно, имитируя задержку туда и обратно 7 секунд или больше, используя:

tc qdisc add dev eth0 root netem delay 7s

Когда я пытаюсь:

ssh -n -o ConnectTimeout=0 WilliamKF@centos5Machine whoami

Это терпит неудачу приблизительно через 1 мин 23 сек с:

Connection closed by 10.35.50.114

Обратите внимание, что ConnectTimeout = 0 означает, что время ожидания никогда не истекает. Кроме того, имитация задержки в оба конца 6 секунд приводит к успешному ssh примерно через 1 мин 32 с.

Могу ли я что-нибудь сделать, чтобы ssh работал в условиях чрезвычайно высокой задержки в Linux? Почему ssh терпит неудачу на этом пороге? Когда я запускаю tcpdump, я не вижу ничего заведомо неправильного: около 51 пакета, какие пакеты tcpdump здесь полезны? Успех занял всего около 41 пакета.

5
Есть ли вероятность, что исправление 30-секундной задержки возможно? Это выше смехотворно высокого уровня. Что происходит, когда вы пинг 10.35.50.114. Что показывает трассировочный маршрут? Everett 13 лет назад 2
Я думаю, что смешное количество прокси-серверов находится на месте .... Я согласен с reeeeeediculous прокси, поэтому я заинтересован в ответах ... дайте мне немного времени, чтобы посмотреть и проверить исходный код. RobotHumans 13 лет назад 0
для этого может потребоваться перекомпилированная библиотека ssh ... это нормально? RobotHumans 13 лет назад 1
@ aking1012 ssh вызывается из приложения C ++, поэтому перекомпиляция ssh и добавление альтернативного определения в приложение приемлемо. WilliamKF 13 лет назад 0
@Everett Я не могу контролировать задержку (на самом деле она достигает только 25 секунд). В этом случае я имитирую только задержку, 10.35.50.114 примыкает к тестовой машине, и соединение замедляется с помощью команды 'tc', чтобы смоделировать задержку. WilliamKF 13 лет назад 0
Просто так я понимаю. У вас есть задержка между вашим клиентом и некоторым сервером при использовании SSH. Вы симулируете эту задержку между вашим клиентом и другим компьютером, который у вас есть? То, что я говорю, так это то, что такая высокая латентность приведет к тому, что ваш клиент и сервер, на который вы пытаетесь войти, примерно в 60 раз больше окружности планеты. Это очень много (см. НЕПРАВИЛЬНО) количество задержки. Существует проблема, которая должна быть устранена между двумя компьютерами. Попытка запрограммировать исправление для такой большой ошибки - действительно неправильный способ решения проблемы. Everett 13 лет назад 2
Причина заключается в следующем: вы пытаетесь разрешить задержку от 25 до 30 секунд для каждой части процесса подключения к сети. Это не просто настроить его, так что ваше приложение ждет от 25 до 30 секунд, вы ждете от 25 до 30 секунд для передачи и ответа КАЖДОГО пакета. Если в протоколе на основе соединения сбрасывается ОДИН пакет, вы ожидаете повторной передачи. Вы НИКОГДА не увидите успешного соединения с 30-секундной задержкой, потому что вы, вероятно, переполните каждый буфер, к которому у вас есть доступ. Everett 13 лет назад 1
Когда я ответил на ваш вопрос (если вы не чувствуете, что я что-то пропустил), может быть, вы могли бы закрыть его? Everett 13 лет назад 0
@Everett Я надеялся услышать от aking1012, который указал, что они будут смотреть на исходный код. Я пытаюсь добиться успеха, мне не говорят, и я принимаю, что это невозможно. WilliamKF 13 лет назад 0

1 ответ на вопрос

2
Everett

Короткий ответ: вы никогда не будете ждать достаточно долго с задержкой в ​​30 секунд на пакет.

Похожие вопросы