Wie kann man ssh angesichts einer riesigen Latenz von 25 Sekunden nutzen?

1829
WilliamKF

Ich muss eine ssh-Verbindung zwischen zwei Linux-Computern herstellen, auf denen Centos v5 ausgeführt wird. Die Latenzzeit kann jedoch 25 Sekunden betragen. Ich finde, wenn ich etwas teste, das sich dieser Konfiguration künstlich annähert, indem ich 7 Sekunden oder mehr Round-Trip-Latenz simuliere, mit:

tc qdisc add dev eth0 root netem delay 7s

Wenn ich es versuche:

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

Es versagt nach ca. 1 min 23 s mit:

Connection closed by 10.35.50.114

Beachten Sie, dass ConnectTimeout = 0 niemals Timeout bedeutet. Die Simulation einer Round-Trip-Latenzzeit von 6 Sekunden führt zu einer erfolgreichen SSH nach etwa 1 Minute und 32 Sekunden.

Gibt es etwas, was ich tun kann, um ssh angesichts extrem hoher Latenz unter Linux zum Laufen zu bringen? Warum scheitert ssh an dieser Schwelle? Wenn ich tcpdump starte, sehe ich nichts offensichtlich falsch. Es gibt ungefähr 51 Pakete. Welche Pakete von tcpdump sind hier hilfreich? Der Erfolg dauerte nur rund 41 Pakete.

5
Gibt es eine Chance, dass die Korrektur der 30 Sekunden Latenz eine Möglichkeit ist? Das ist unglaublich lächerlich. Was passiert, wenn Sie 10.35.50.114 pingen? Was zeigt die Routenführung? Everett vor 13 Jahren 2
Ich denke, eine lächerliche Menge an Proxying ist vorhanden ... Ich stimme den reeeeeediculous-Proxies zu, also bin ich an einer Antwort interessiert ... Gib mir etwas Zeit, um nachzuschauen und den Quellcode zu überprüfen. RobotHumans vor 13 Jahren 0
Es kann eine neu kompilierte SSH-Bibliothek erforderlich sein ... ist das in Ordnung? RobotHumans vor 13 Jahren 1
@ aking1012 Die ssh wird aus einer C ++ - Anwendung heraus aufgerufen. Es ist daher akzeptabel, die ssh neu zu kompilieren und die alternative Definition in die Anwendung einzubinden. WilliamKF vor 13 Jahren 0
@Everett Ich kann die Latenz nicht kontrollieren (sie erreicht eigentlich nur 25 Sekunden). In diesem Fall simuliere ich nur die Latenzzeit, die 10.35.50.114 befindet sich neben der Testmaschine und die Verbindung wird mit dem Befehl 'tc' abgebremst, um die Latenzzeit zu simulieren. WilliamKF vor 13 Jahren 0
Nur so verstehe ich. Sie haben eine Latenz zwischen Ihrem Client und einem Server, wenn Sie SSH verwenden. Sie simulieren diese Latenz zwischen Ihrem Client und einem anderen Computer, den Sie zur Verfügung haben? Was ich damit sagen möchte, ist, dass eine derart hohe Latenz Ihren Client und den Server, auf dem Sie sich anmelden möchten, ungefähr 60-mal so weit entfernt wie der Planet. Das ist eine Menge (siehe UNGODLY) Latenzzeit. Zwischen den beiden Computern muss ein Problem behoben werden. Der Versuch, zu programmieren, um diesen großen Fehler zu korrigieren, ist wirklich der falsche Weg, um das Problem anzugehen. Everett vor 13 Jahren 2
Der Grund ist folgender: Sie versuchen für jeden Teil des Netzwerkverbindungsprozesses eine Latenzzeit von 25 bis 30 Sekunden einzuhalten. Dies ist nicht nur so eingerichtet, dass Ihre Anwendung 25 bis 30 Sekunden wartet. Sie warten 25 bis 30 Sekunden auf die Übertragung und Antwort jedes Pakets. Wenn EIN Paket in einem verbindungsbasierten Protokoll abgelegt wird, warten Sie auf die erneute Übertragung. Sie werden NIEMALS eine erfolgreiche Verbindung mit einer Latenz von 30 Sekunden sehen, da Sie wahrscheinlich jeden Puffer überlaufen, auf den Sie Zugriff haben. Everett vor 13 Jahren 1
Da ich Ihre Frage beantwortet habe (es sei denn, Sie haben das Gefühl, etwas vermisst zu haben), könnten Sie sie vielleicht schließen? Everett vor 13 Jahren 0
@Everett Ich hatte gehofft, von aking1012 zu hören, wer angedeutet hat, dass sie sich den Quellcode ansehen würden. Ich versuche erfolgreich zu sein, es wird mir nicht gesagt, dass es nicht geht. WilliamKF vor 13 Jahren 0

1 Antwort auf die Frage

2
Everett

Kurze Antwort, Sie werden nie lange genug warten, mit einer Latenz von 30 Sekunden pro Paket.

Verwandte Probleme