<WRAP clear></WRAP>
^ Message und Richtung ^^^ Ausgelöste Messages \\ name (an, blockirung) ^ ... blocks ... ^^
^ ::: ^^^ ::: ^ Who ^ Whom ^
| <- |ticket | |
| <- |toPlayer | |
| <- |player/state | |
| |register | -> | player (alle, akkumulierbar) \\ ticket (caller, blocken am caller) | caller | caller |
| |unregister | -> | player (alle, akkumulierbar) | caller | caller |
| |move | -> | state (alle, akkumulierbar) \\ toPlayer (player, blocken am game) | any player | game |
| |requestPlayer/requestState | -> | player/state/eigene message? (caller, blocken am caller) | caller | caller |
Abbruch durch server initiiert
"register" anstatt "setup", denn dafür gibt es ein passendes "unregister".
"keepAlive" anstatt "autoUnregister", denn es i
Timeout bis zum register erforderlich.
Hm, eher ein "keepAlive", dann bleibt er nur offen, wenn bis dahin der Adapter noch nicht abgestürzt ist. (kann auch als Ping benutz werden)
Am besten keine Antwort (Abbruch im Fehlerfall)
__ Argumente __
?move %%:%% str
:Der move als Textbeschreibung. Das Spiel muss damit umgehen können. Es wird hier einfach nur durchgereicht.
__ Argumente __
?from %%:%% int
:Erster player/state (von 0 weg)
?to %%:%% int = -1
:Letzter player/state (von 0 weg). \\ -1 = Bis zum letzten (kann vom Master beschnitten werden?)
Die player/state ID muss im Datensatz vorkommen, da protocol buffers keine dictionarys kennt.
__ Return __
?players/states %%:%% player/state[]
:Player/State array
?total %%:%% int
:Absolute Anzahl an verfügbaren players/states (um heraus zu finden, ob alle geschickt wurden (pagination))
"total" ist auch deshalb wichtig, damit bei einem ungültigen Bereich (außerhalb verfügbarer Daten) dennoch eine Antwort kommt.
