Ich versuche, ein Turn-Base-Spiel über XMPP zu entwickeln. (Die einzige Lösung, die ich für Multiplattform-Spiel gefunden habe). Ich kann Nachrichten ohne Probleme senden. Wenn der andere Benutzer nicht online ist, speichern Sie den Server (OpenFire) für die spätere Zustellung.
Das Problem tritt auf, wenn ein Gerät das Netzwerk wechselt (von 3G auf WiFi wechseln, 3G IP ändern ...) oder das Gerät das Netzwerk verloren hat (3G, WLAN oder Verbindungsverlust). Der Server denkt, dass das Gerät online ist und sendet die Nachricht, aber es kommt (obviusly) nie an, so Paket ist verloren.
Ich kenne eine Lösung. Implementiere ACK über mein Spielprotokoll, aber ich mag diese Idee nicht sehr. Hast du einen anderen Vorschlag? Ich denke, das ist ein Serverproblem. Kennen Sie einen anderen Server, der TCP oder ACK implementiert?
Danke !!
EDIT: Ich mache das: Verbinden Sie das Gerät mit dem Server. Ich drehe die 3G- und WLAN-Verbindung zum Gerät herunter. Android und der Server denken immer noch, dass die Verbindung lebendig ist.
PD: Ich bitte um Openfeint für die Multiplayer-API, aber sie haben mich nicht gefragt ...
Obwohl BOSH wahrscheinlich in diesem Fall funktioniert, ist XEP-0198 eine weitere Option: Stream Management. Dies ermöglicht Ihnen, die gesamte Leistung eines vollständig verbundenen Sockets, zusammen mit schnellen Wiederverbinden, positiven Ackern und Warteschlangen zu erhalten, während Sie nicht in beide Richtungen deaktiviert oder getrennt sind.
Unter bestimmten Bedingungen ist TCP / IP nicht zuverlässig. Aus diesem Grund können ACKs, Nachrichtenquittungen, IQs oder andere Erweiterungen in XMPP dieses Problem lösen
Ich habe im Laufe der Jahre viele mobile Programme gemacht, oft auch mit Openfire. Aber ich habe keine verlorenen Nachrichten gesehen. Ich nehme also an, dass entweder in der Bibliothek, die Sie auf Android verwenden, oder in der von Ihnen verwendeten Openfire-Version ein Problem vorliegt.
Anstelle von rohen Sockets können Sie auch BOSH verwenden:
Ссылка
BOSH basiert auf WebRequests wie Comet und funktioniert sehr gut in Umgebungen, in denen Sie häufig die Verbindung wechseln oder verlieren. Es kann die Verbindung aufrecht erhalten, bis das Netzwerk wieder verfügbar ist, und führt nicht zu Verbindungsabbrüchen, wenn eine oder mehrere Anforderungen in einer Zeile fehlschlagen.
Problem für mich ist, dass ich die Offline-Nachrichten-Richtlinie auf "Immer speichern" und damit XEP-0184 nicht wirklich hilft, um festzustellen, ob eine Nachricht nicht an seinen Empfänger geliefert wird.
Bereitstellen dieses Szenarios: - Ich habe 2 Benutzer im Chat, nennen sie A und B - A sendet B eine Nachricht, während die Verbindung von B gerade verloren gegangen ist - Die Nachricht wurde gelöscht und A wird nicht benachrichtigt - In diesem Fall weiß A nicht, dass die Nachricht gelöscht wurde, es wird nur angenommen, dass die Nachricht an den Server geliefert wird, der Server wird es schließlich an B liefern - B verliere die Nachricht für immer
Also habe ich vorübergehend eine Arbeit dafür gemacht ... Ich speichere all die Nachrichten, die nicht zugestellt werden (dh ich habe die Nachrichtenübermittlungsbestätigung nicht erhalten) in eine Warteschlange, dann periodisch (sagen wir 6 Minuten - es ist die Zeit, wenn diese toten Verbindungen gelöscht wurden. Prüfe jede Nachricht der Warteschlange, um zu sehen, ob der beabsichtigte Empfänger "Online" ist und die Quittung immer noch nicht empfangen wird ... Wenn es der Fall ist, markiere ich diese Nachricht als "Fehlgeschlagene Zustellung"
Das ist eine ziemlich schlimme Art, das Problem zu beheben (bitte geben Sie an, wenn Sie einen besseren Weg dafür haben). Ich denke, das Beste ist, den Server dazu zu haben: Wenn die Nachricht nicht geliefert werden konnte und die Offline-Nachrichtenrichtlinie "Immer speichern" lautet, speichern wir sie für eine verzögerte Zustellung in "ofoffline".
Dies ist ein alter, aber ich habe kürzlich ein solches Problem gelöst. Es hat mir geholfen, wenn ich die XMPP-Ressource (den letzten Teil der vollständigen JID) zu etwas vernünftigem setze, wenn ich eine Verbindung aufbaue. Andernfalls wird es zufällig bei jeder Wiederverbindung erzeugt - und das ändert die vollständige JID.