Protokół Komunikacji

Do komunikacji użyjemy java RMI (Remote Method Invocation). W mechanizmie tym obiekty zdalne rejestrowane są pod wybranymi nazwami w serwisie RMI Registry. Aplikacja kliencka ściąga z RMI Registry tzw. stub tego obiektu, który umożliwia komunikację z obiektem zdalnym tak jakby odbywała się ona lokalnie. Są dostępne dwie metody przekazywania argumentów: przez wartość i przez referencję. W pierwszym przypadku obiekt musi implementować interfejs Serializable, a w drugim Remote.

Zarówno serwer jak i klient mają interfejsy w formacie niezbędnym do zastosowania RMI i implementację interfejsu. W trakcie gry jeden gracz może założyć serwer, drugi gracz jest jego klientem. W zastosowanym przez nas podejściu obaj gracze są klientami, z tym że lokalny gracz rejestruje serwer, a zdalny gracz wyszukuje i dołącza się do niego. Takie podejście sprawia, że serwer przetwarza informacje związane z interakcją użytkowników z silnikiem gry, a następnie rozsyła powiadomienia o zmianach każdemu z graczy (także sobie). Z taką różnicą, że do gracza lokalnego informacja ta trafi bezpośrednio (przezroczystość interfejsów).

Poniżej przedstawiliśmy przykładowy przypadek użycia. Polega on na stworzeniu serwera, zarejestrowaniu graczy, a następnie wydaniu polecenia pingServer() na graczu zdalnym. On z kolei wywołuje ping() na serwerze, co skutkuje odpowiedzią zwrotną pong() dla gracza zarówno lokalnego jak i zdalnego.

Stworzenie lokalnego klienta i rejestracja klientów na serwerze:

Stworzenie zdalnego klienta, „druga strona” rejestracji zdalnej, komunikacja ping-pong:

W danej chwili nie mamy dostatecznej wiedzy, żeby w pełni sprecyzować protokół komunikacji. Rozwiązanie przez nas przedstawione daje gotowy szkielet do wypełniania protokołu. Dodanie nowej funkcjonalności wiąże się jedynie z dodaniem metody do interfejsu i implementacji.

Przykładowo:

Serwer:

• przesunGracza(int x, int y)
• uzyjPulapki()

Klient:

• zwiekszOdkrytyObszar(int x, int y, int r)
• utrataZycia(int punkty)

W tworzeniu protokołu komunikacji najtrudniejszym zadaniem jest utrzymanie synchronizacji stanu gry na każdej platformie gry. Struktura klient - serwery zwiększa koszty obliczeniowe po stronie serwera, ale jednocześnie ułatwia ujarzmić synchronizację.

Mimo to, może wystąpić scenariusz, w którym gracz zdalny przed dostaniem powiadomienia o zmianie stanu gry (np. przez gracza lokalnego) będzie próbował wykonać operację, która po zmianie stanu byłaby niemożliwa. Rozwiązaniem takiego problemu mogłoby być wprowadzenie sesji, które blokowały by dostęp do kanału komunikacji dla innych graczy poza tym posiadającym aktualnie monitor.