Utracone wiadomości przez XMPP na urządzeniu odłączonym

Question

Próbuję opracować grę z podstawową turą ponad XMPP. (Jedyne rozwiązanie, które znalazłem w wieloplatformowej grze). Mogę wysyłać wiadomości bez problemów. Jeśli drugi użytkownik nie jest online, serwer (OpenFire) zapisze go do późniejszego dostarczenia.

Problem pojawia się, gdy urządzenie zmienia sieć (zmiana z 3g na WiFi, zmiana 3g IP ...) lub urządzenie zgubiło sieć (wyłącz 3g, wifi lub utracone połączenie). Serwer uważa, że ​​urządzenie jest w trybie online i wysyła wiadomość, ale nigdy jej nie dotrze, więc pakiet zostanie utracony.

Znam jedno rozwiązanie. Zastosuj ACK do mojego protokołu gry, ale nie podoba mi się ten pomysł. Czy masz jakieś inne sugestie? Myślę, że to jest problem z serwerem. Czy znasz inny serwer z implementacją TCP lub ACK?

Dziękuję!

EDYCJA: Robię to: Podłącz urządzenie do serwera. Wyłączam łączność 3G i Wi-Fi z urządzeniem. Android i serwer wciąż myślą, że połączenie jest żywe.

http://issues.igniterealtime.org/browse/SMACK-331

PD: Pytam się OpenFeint dla multiplayer one api, ale nie asnwer mnie ...

Answer 1

pod pewnymi warunkami TCP/IP nie jest wiarygodne. Właśnie dlatego ACK, potwierdzenia wiadomości, IQ lub inne rozszerzenia w XMPP mogą rozwiązać ten problem.

Zrobiłem wiele programowania mobilnego na przestrzeni lat, często także z Openfire. Ale nie widziałem zagubionych wiadomości. Zakładam więc, że jest problem w bibliotece używanej w systemie Android lub w używanej wersji Openfire.

Zamiast gniazd surowych można również użyć Bosh:
http://xmpp.org/extensions/xep-0124.html
BOSH opiera się na WebRequests jak Comet i działa bardzo dobrze w środowiskach, gdzie często przełącznik lub luźne połączenie. Może utrzymywać połączenie przy życiu do momentu powrotu sieci i nie spowoduje utraty połączenia, gdy jedno lub więcej żądań zakończy się niepowodzeniem z rzędu.

Answer 2

Chociaż BOSH prawdopodobnie będzie działać w tym przypadku, inną opcją jest XEP-0198: Zarządzanie strumieniem. Umożliwi to uzyskanie pełnej wydajności w pełni połączonego gniazda, a także szybkich ponownych połączeń, pozytywnego potwierdzenia i kolejkowania, podczas gdy nie zostanie potwierdzone lub rozłączone w obu kierunkach.

Answer 3

Ja też natknąłem się na tę kwestię i próbowałem znaleźć odpowiedni sposób, aby to rozwiązać.

Problem polega na tym, że ustawi politykę wiadomości offline na "Zawsze zapisuj" i dlatego XEP-0184 nie pomaga w ustaleniu, czy wiadomość nie jest dostarczana do odbiornika.

Zapewnienie tego scenariusza: - Mam 2 użytkowników na czacie, nazywają je A i B - A wysyła B wiadomość natomiast połączenie B jest po prostu zabłądził - Komunikat został usunięty i A nie jest powiadamiany - W tym przypadku A nie wie, że wiadomość została usunięta, po prostu zakłada, że ​​wiadomość jest dostarczana na serwer, serwer ostatecznie dostarczy ją do B - B utraci wiadomość na zawsze

Więc tymczasowo włożę do tego ... przechowuję wszystkie wiadomości, które nie zostały dostarczone (npnie otrzymałem pokwitowania dostarczenia wiadomości) do kolejki, a następnie okresowo (powiedzmy 6 minut - jest to czas, w którym te niedziałające połączenia zostały wyczyszczone), sprawdź wszystkie wiadomości w kolejce, aby sprawdzić, czy zamierzonym odbiorcą jest "Online", a pokwitowanie nadal nieodebrane ... Jeśli tak jest, to oznaczam tę wiadomość jako "Nieudana dostawa"

To jest dość przerażający sposób, aby to naprawić (poinformuj, jeśli masz lepszy sposób na zrobienie tego). Myślę, że najlepszą rzeczą do zrobienia jest posiadanie serwera, aby to zrobić: jeśli wiadomość nie została dostarczona, a polityka wiadomości w trybie offline jest "Zawsze zapisuj", to przechowujemy ją do "ofoffline" w celu opóźnienia dostawy.

Answer 4

To jest stary, ale ostatnio rozwiązałem taki problem. Pomogło mi to, gdy ustawiłem zasób XMPP (ostatnia część pełnego JID) na coś sensownego podczas budowania połączenia. W przeciwnym razie będzie generowany losowo na każdym ponownym połączeniu - i to zmieni pełny JID.