2013-01-12 13 views
7

Do komunikacji między graczami na platformie Android używam serwera WebSocket i TooTallNate's Java library po stronie klienta, aby umożliwić obsługę WebSocket w aplikacji na Androida. Aby jasno to podkreślić, obsługa WebSocket w przeglądarkach mobilnych nie jest dla mnie ważna.Obsługa WebSocket na urządzeniach mobilnych

Niestety, użytkownicy zgłaszają, że występują problemy, takie jak awarie połączenia lub nieodebrane wiadomości. Czy jest to ogólny problem WebSockets na urządzeniach mobilnych (zablokowane porty, zapory ogniowe, mobilne połączenie internetowe), czy jest to prawdopodobnie usterka kodu po stronie klienta?

Czy masz doświadczenie z bibliotekami klientów WebSocket, takimi jak wyżej? Właśnie odkryłem autobahn.ws for Android - ale nie wiem, czy warto przestawić się z mojej obecnej biblioteki (patrz wyżej).

Co z WAMP? Czy technologia WebSocket nie jest dokładnie odpowiednim rozwiązaniem, więc powinienem użyć pod-protokołu (?) WAMP?

Odpowiedz

4

Każda nowa technologia ma nowy zestaw problemów. W przypadku WebSocket jest to kompatybilność z serwerami proxy, które pośredniczą w połączeniach HTTP w większości sieci firmowych. Protokół WebSocket używa systemu aktualizacji HTTP (który jest zwykle używany w protokole HTTP/SSL) do "uaktualnienia" połączenia HTTP do połączenia WebSocket. Niektóre serwery proxy tego nie lubią i zerwą połączenie. Dlatego nawet jeśli dany klient używa protokołu WebSocket, nawiązanie połączenia może być niemożliwe.

+0

Dziękujemy! Czy to oznacza, że ​​niezależnie od używanej biblioteki klienta i urządzenia mobilnego (lub operatora), WebSockets zawsze będzie wątpliwe z powodu serwerów proxy? Z drugiej strony, kiedy korzystasz z mobilnych planów transmisji danych, zazwyczaj nie masz pośredników pośrednich, prawda? – caw

+0

dla pierwszego pytania. Tak dla drugiego pytania. To zależy, zwykle mamy. – atta

+0

również, czy możesz podzielić się swoim kodem na połączenie z klientem i serwerem websockets i komunikator? – atta

8

Miał te same błędy ze złym połączeniem z gniazdem sieciowym w niektórych sieciach komórkowych. Rozwiązano je przez:

(1) przesuwając porty: Przenoszenie nad serwerem a klientem dla websocket nad do portu SSL (port 443)

(2) ping keep-alive: Wysyłanie okresowe "ping" wiadomości z klientem na serwer co X sekund i czekając na "ponga", aby powrócić z serwera. Jeśli serwer nie da "ponga" w ciągu Y sekund, zrestartuj połączenie na kliencie.

Implementacja (1) zabierze Cię tam w większość drogi.

+0

Stwierdziłem, że ping jest dość ważny, ponieważ obecny stan (od 2016 r.) Klientów websocket na Androida i iOS nie radzi sobie z bezczynnymi spadkami połączeń w bardzo słabym pokryciu, a nawet w niektórych przypadkach za pośrednictwem Wi-Fi. – Nick

Powiązane problemy