Rzuć długopis w grę ramową online

Question

Pracuję nad grą przeglądarkową ze strukturą gry i zdecydowanie potrzebuję longpollingu, ale nie bardzo rozumiem, jak z niej korzystać. WebSockets byłby idealny do tego, ale nie jest jeszcze obsługiwany przez wiele przeglądarek.

Oto, co chcę zrobić: gdy użytkownik się zaloguje i przejdzie do kontrolera gier, chcę nawiązać połączenie i pozostawić je otwarte. Chcę to zrobić dla wszystkich użytkowników online, więc mogę wyświetlić ich listę na stronie, aby mogli się ze sobą bawić. Przyjrzałem się the documentation, ale nie rozumiem, jak mógłbym to zaimplementować w moim przypadku. Ponieważ po prostu nie ma niczego, co chciałbym obliczyć (w przykładzie generują plik pdf), chcę tylko, aby połączenie pozostało otwarte.

Zastanawiam się też, w jaki sposób powinienem śledzić wszystkie te otwarte połączenia? Właśnie teraz mam kolumnę online w mojej tabeli użytkowników w bazie danych, którą aktualizuję. Za każdym razem, gdy ktoś łączy się, muszę zaktualizować bazę danych. Czy są na to lepsze sposoby, czy jest to w porządku?

I wreszcie, zakładając wszystkie powyższe prace. Kiedy gracz A, wybiera gracza B do gry: jak powiadomić gracza B o tym? Czy po prostu wyślę trochę kodu JSON i zmieniam stronę za pomocą javascriptu po stronie odtwarzacza B, czy też wyślę go na zupełnie inną stronę? Nie wiem, jak się komunikować, gdy ustanowione są dwa połączenia i gra się rozpoczęła.

Answer 1

Po pierwsze, myślę, że musisz docenić różnicę między Websockets i Long Polling.

Websockets tworzy połączenie i utrzymuje je otwarte, dopóki przeglądarka nie zakończy sesji, za pośrednictwem niektórych javascript lub użytkownika przechodzącego ze strony. Dałoby to pożądany charakter tego, o co prosisz. Patrząc na przykład na czacie w pobraniu Play pokaże się, jak cała aplikacja czatu jest obsługiwana za pomocą Websockets. Po odpowiedź Pere'a na temat bezpaństwowości Play. Twórcy Play zasugerowali, że pojedyncze połączenie Websocket, niezależnie od tego, jak długo jest ono otwarte i ile żądań jest wysyłanych z powrotem, jest traktowane jako pojedyncza transakcja. Dlatego zapisywanie do bazy danych pomiędzy każdym żądaniem Websocket nie jest potrzebne (ponownie widać, że nic nie jest zapisywane w przykładzie czatu). Korzystając z tej metody, można oczekiwać zapisania szczegółów po zamknięciu WebSocket, a nawet wszystkich Websockets, w zależności od przypadku użycia.

Długie pobieranie powoduje natomiast nawiązanie połączenia z serwerem, a serwer po prostu czeka, aż pojawi się coś, co można odesłać do klienta. Jeśli chcesz przekazać dowolne dane na serwer, zrobiłbyś to jako oddzielne żądanie AJAX, więc w efekcie miałbyś otwarte dwa żądania naraz. Nie musisz wiedzieć, kiedy użytkownik się wylogowuje, chyba że wyślesz takie żądanie, gdy opuszczą stronę, aby serwer wiedział, że odszedł, ale nie zawsze się to udaje. Long Polling może działać, ale nie jest tak dobrym rozwiązaniem jak Websockets, ale jak już mówisz, nie jest to jeszcze szeroko obsługiwane.

Moja sugestia to zapoznanie się z przykładem czatu (ponieważ ma on opcję Długie pobieranie i wersję Websockets). To najskuteczniejszy sposób, aby uzyskać dostęp do swoich wymagań.

Co do ostatniego zapytania dotyczącego sposobu powiadomienia drugiego gracza. W przypadku Long Polling wystarczy odpowiedzieć na zawieszoną prośbę za pomocą JSON. Dzięki websockets możesz wysłać zdarzenie z powrotem do klienta. Ponownie, oba podejścia można dość wyraźnie określić na przykładzie czatu.

Mam również written a Blog post na stronach internetowych, które mogą pomóc ci lepiej zrozumieć ten proces.

Answer 2

Na stronie Websocket, jak widać here (pierwsza odpowiedź) wsparcie nie jest takie złe, a jeśli masz jakiś problem z przeglądarką, masz awarię JavaScript. Uprościłoby to twój scenariusz, ponieważ długie sondowanie może być bardziej skomplikowane w zarządzaniu.

W kwestii śledzenia, ponieważ Play jest bezstanowy, musisz zapisać flagę w bazie danych i usunąć ją, gdy zamkną połączenie. W przeciwnym razie łamiesz bezpaństwowość.

O zgłoszeniu należy wysłać wiadomość do B, ale nie przenosić ich na inną stronę, ponieważ może to być mylące i powodować złą satysfakcję użytkownika. Użyj Jsona, aby wysłać wiadomość (w div), informując ją o rozpoczęciu gry lub prośbie o grę.

Answer 3

Nie używam frameworka "play".

Ale ostatnio badałem i majstrowałem przy użyciu długiego sondowania opartego na http. Sieci Web, jeśli są dostępne, są znacznie bardziej odpowiednie dla wiadomości w czasie rzeczywistym!

Jeśli chodzi o długi głos, okazało się, że zastosowanie analogii "ładunków ciężarówek" bardzo skutecznie pomogło mi w długich wyborach. Oto mała uwaga Pisałem na ten temat:

http://dvb.omino.com/blog/2011/http-comet-realtime-messages/

Być może ty lub przyszłe greppers znaleźć przydatne.

Answer 4

Warto również rzucić okiem na projekt Juggernaut oparty na node.js i Redis, który zapewnia "połączenie w czasie rzeczywistym między serwerami i przeglądarkami klienta". Korzystając z klienta Java Redis, takiego jak Jedis, z łatwością powinieneś móc zintegrować całość ze strukturą Play!