Was passiert beim Ausführen eines Jabber-Clients (oder was sollte passieren), wenn das Netzwerk gewechselt wird (oder wenn die Verbindung unterbrochen wird und das GSM/UMTS-Modem sich wieder verbindet)?
Kann ein mobiler Android-Jabber-Client (z. B. Jabiru ) in solchen Situationen schlau sein?
Worst-Case-Szenario, das ich mir vorstellen kann: Client kümmert sich nicht darum, die TCP-Verbindung (über TLS) zum Jabber-Server geht verloren, der Jabber-Status (aus der Ferne angezeigt) ist falsch und es gibt ein Zeitfenster, in dem Nachrichten (von Freunden) verloren gehen.
Ich habe einen solchen Worst Case zum Beispiel bei einem Standard-Jabber-Client auf einem Laptop mit einer unzuverlässigen UMTS-Verbindung beobachtet.
Wenn ich einen Laptop verwende, kann ich meine Jabber-Sitzung einfach wie folgt abschirmen:
autosshmit einem System mit stabiler Netzwerkverbindung verbinden und direkt ausführenscreen -RdscreenBei einem Verlust der mobilen Internetverbindung ist die Verbindung zum Jabber-Server also weiterhin in Ordnung. Und autosshverbindet sich automatisch wieder und verbindet sich wieder mit der laufenden Bildschirmsitzung, wenn eine neue mobile Verbindung hergestellt wird.
Ist eine ähnliche Einrichtung erforderlich, wenn Jabber auf einem Android-Gerät verwendet wird?
Oder gibt es Jabber-Protokollerweiterungen für mobile Clients, die tatsächlich dazu beitragen, den Verlust von Nachrichten usw. in Netzwerk-Ein/Aus-Situationen zu vermeiden (während sie mit einem Jabber-Server verbunden sind)?
Ich bin mir nicht sicher, ob diese Frage bei Android-Enthusiasten zum Thema gehört. Aber ich arbeite mit XMPP und Android, also hier meine Antwort:
Wie Lie Ryan bereits sagte , ist ein Handover von einer Mobilfunkzelle zur anderen fast immer für den TCP-Stack auf Android-Geräten transparent. Es gibt jedoch Situationen, in denen sich die IP Ihres Android-Geräts ändert. Dies sind in der Regel GSM/UMTS <-> WLAN-Switches, die dazu führen, dass die TCP-Verbindung für den XMPP-Client unbrauchbar wird.
Unter Android ist die Standard-XMPP-Bibliothek, die die meisten Clients verwenden – abgesehen davon, dass sie ihre eigene proprietäre haben – (a)Smack : Clients, die (a)Smack mit der Standardkonfiguration verwenden, werden eine Verbindungsänderung nicht rechtzeitig bemerken. Aber es gibt Hoffnung: XMPP-Ping-Support ist im Smack-Trunk und wird mit Release 3.3 ausgeliefert. Die meisten aSmack-Apps verwenden bereits eine aSmack-Version, die dies unterstützt, und müssen nur entsprechende Maßnahmen implementieren.
Auf der anderen Seite ist es die Aufgabe des XMPP-Servers, Ihre Anwesenheit nach einem (serverdefinierten) Timeout für das Erreichen des letzten Clients der betreffenden JID auf nicht verfügbar (offline) zu setzen.
Es ist also nicht notwendig, Workarounds zu bauen, wenn Sie einen richtigen XMPP-Client verwenden, aber Sie müssen möglicherweise mit Ghost-Status-Situationen leben, die sich nach einigen Minuten auflösen sollten.
Es gibt ein nettes XEP (XMPP Extension), das die Wunderwaffe für mobile XMPP-Verbindungen wäre: XEP-0198 - Stream Management . Sie können darüber in Ge0rgs Blog lesen .
Für (a)Smack wird daran gearbeitet . Aber es wird eine Weile dauern, bis es stabil ist, und Sie brauchen auch Serverunterstützung für XEP-0198.
Ich bin kein Experte für mobile Netzwerke, aber AFAIK sollte der TCP-Stack die mobile Übergabe transparent handhaben, Anwendungsprogramme sollten nicht wissen müssen, dass die mobile Netzwerkschicht von Mobilfunkmast zu Mobilfunkmast wechselt. Aus Sicht des Anwendungsprogramms gibt es nur eine durchgehende Verbindung.
Der einzige Grund, warum ich mir vorstellen kann, was Sie im Laptop-Jabber-Client sehen, ist, dass er beim Öffnen einer TCP-Verbindung mit langer Laufzeit kein Keepalive verwendet hat. Wenn über einen längeren Zeitraum keine Übertragung stattfindet, kann einer der zwischengeschalteten Knoten im Netzwerk (normalerweise die Firewall) entscheiden, die Verbindung zu beenden (normalerweise, um Ressourcen für andere aktive Verbindungen zu sparen), und der Server hatte daher keine Chance um dem Client zu sagen, dass er sauber beenden soll. Wird Keepalive nicht für eine lang andauernde Verbindung verwendet, kann der Client nicht erkennen, dass die Verbindung unterbrochen wurde, da die einzige Möglichkeit für einen Client, eine unterbrochene Verbindung zu erkennen, darin besteht, dass er versucht hat, ein Paket zu senden, und dauerhaft fehlgeschlagen ist.
Keepalive bewirkt, dass der TCP-Stack den Server regelmäßig mit ACK-Paketen der Länge null anpingt, daher werden zwischengeschaltete Knoten Ihre lang andauernde Verbindung als noch aktiv betrachten und sie nicht beenden.