Ich habe eine Client-/Server-Netzwerkanwendung, die einen Boost ASIO TCP-Socket verwendet. Der Client läuft auf einem eingebetteten Linux-System, auf dem mehrere Netzwerkschnittstellen verfügbar sind (WLAN, Mobilfunk usw.). Zu jedem Zeitpunkt ist nur eine Netzwerkschnittstelle aktiv und hat eine signierte IP-Adresse. Wenn die Schnittstelle ausgefallen ist, ist eine andere Schnittstelle aktiv und hat eine signierte IP-Adresse. Mein Problem ist, dass die Anwendung, wenn sie einen TCP-Socket in einer verfügbaren Schnittstelle erstellt, Daten an den Remote-Server übertragen kann. Wenn aber die Schnittstelle ausgefallen ist und eine andere Schnittstelle aktiv ist, überträgt die Client-Anwendung die Daten trotzdem an den Remote-Server und verwendet dabei dieselbe ausgefallene Schnittstelle, sodass der Server die Daten nicht empfangen kann. Ich dachte, dass die Linux-Betriebssystemroute in der Lage sein sollte, ein Failover der Netzwerkschnittstelle zu handhaben, und die TCP-Benutzeranwendung sich nicht um die Änderung der Netzwerkschnittstelle kümmern muss. Ich freue mich über alle Tipps zur Reparatur des Programms.
Dasselbe Problem sehe ich auch auf einem Laptop mit Ubuntu 18 und sowohl mit Ethernet als auch mit WLAN: Wenn ich bei angeschlossenem Ethernet eine SSH-Verbindung zu einer Remote-Site ausführe, ist die WLAN-Verbindung nach dem Abziehen des Ethernet-Kabels zwar noch vorhanden, aber SSH ist eingefroren und kann die Verbindung nicht über die OS-Route umleiten.
Danke schön.
Mit freundlichen Grüße,
- J
Sprechen Sie von einer bestehenden TCP-Verbindung, die die Schnittstellen wechselt, wenn eine Schnittstelle ausfällt? Das wird nicht funktionieren, TCP ist kein Multihoming, daher ist dies ein Fehler des Protokolls und nicht von Linux. Andererseits werden beim Abhören des TCP-Sockets standardmäßig alle Schnittstellen verwendet, ebenso wie beim Öffnen einer TCP-Verbindung.
Ja, eine bestehende TCP-Verbindung wechselt die Schnittstellen, wenn eine Schnittstelle ausfällt.
Wenn Sie in Ihrer Client-Server-Anwendung beide Seiten steuern, sollten Sie die Verwendung eines Multihoming-Protokolls wie SCTP oder Multipath TCP in Betracht ziehen.
Ja, ich steuere beide Seiten der Client-Server-Anwendungen. Ich verwende den Boost ASIO-Socket und werde prüfen, ob Boost Multipath TCP unterstützt oder nicht.
Es gibt andere Möglichkeiten, das Failover physischer Verbindungen zu handhaben, etwa Bonding. Dabei ist jedoch ebenfalls erforderlich, dass Sie in der Lage sind, beide Seiten zu kontrollieren.
Ja oder nein. Ich kontrolliere beide Seiten der Client-Server-Anwendungen, aber ich kontrolliere nur die Server-Plattform-Site, nicht die Client-Plattform-Site. Ich kann der Client-Site vorschlagen, den Netzwerkbetrieb zu ändern. Wird das funktionieren?
Danke schön.
Antwort1
Sprechen Sie von einer bestehenden TCP-Verbindung, die die Schnittstelle wechselt, wenn eine Schnittstelle ausfällt? Das wird nicht funktionieren, TCP ist kein Multihoming, also ist das ein Fehler des Protokolls und nicht von Linux. AndererseitsHörenauf TCP-Socket werden standardmäßig alle Schnittstellen verwendet, ebensoÖffnungeine TCP-Verbindung.
Wenn Sie beide Seiten in Ihrer Client-Server-Anwendung steuern, sollten Sie ein Multihoming-Protokoll verwenden wieSCTPoderMultipath-TCP.
Ich dachte, dass die Linux-OS-Route in der Lage sein sollte, ein Failover der Netzwerkschnittstelle zu handhaben
Das ist nicht der Fall und hat es auch nie getan, und das gilt auch für andere vorhandene Implementierungen von TCP und UDP. Ebenso wenig können Sie problemlos mehrere ISPs gleichzeitig verwenden, was eine häufig gestellte Frage ist.
Es gibt andere Möglichkeiten, das Failover physischer Verbindungen zu handhaben, etwa Bonding. Dabei ist jedoch ebenfalls erforderlich, dass Sie in der Lage sind, beide Seiten zu kontrollieren.
Bearbeiten
Je nachdem, was sich zwischen Ihrem Server und Ihrem Client befindet, lässt dieser Teil des Netzwerks SCTP möglicherweise durch oder nicht (im Zweifelsfall testen).
Bei den meisten eingebetteten Linux-Systemen sollten Sie in der Lage sein, den Kernel neu zu kompilieren, was Sie für Multipath TCP benötigen.
Wenn dies nicht möglich ist, bleibt Ihnen wahrscheinlich dieses Problem erspart. Die einzige Problemumgehung besteht dann darin, festzustellen, ob eine Schnittstelle ausfällt, und die Verbindung vom Client aus erneut zu öffnen (vorausgesetzt, der Server hat eine bekannte IP-Adresse).