Open fendor opened 7 years ago
Collaborating document on HackMd for further discussion.
@fendor The connection mechanism is not the best fit for The Elm Architecture.
Ack!
is not a goot choice for Response. This should be done by an elm-bridge Object with a better name (referencing the type of request).
Using Websockets as-is does not detect reconnection
Reconnection-token is not the best solution since it does not allow reconnection between reloads (e.g. when frontend changes and gets hot-realoaded)
Protocol Definition
We would need a formal definition what kind of messages can be sent between a client and the server.
So far we need this messages for sure:
For Setup:
ACK!
if there are enough free slots, otherwise drop the connection.For Game Playing:
ACK!
or is it assumed that he got the message?After the game has finished:
Discussion: Should the server offer to restart the game?
Messages by Client and Server
Client
Client Connect
This is not an explicit message
Personal Information
Reconnect
Disconnect
This should be explicit to determine if the disconnecting player wants to reconnect later. To be discussed: Should it really be this way? Most clients probably won't send this message, but on the other hand, if a player completly disconnects, the game is probably over anyways.
For now: some temporal message
Client sends move
Server
ACK!
new clientImplicit
ACK!
. This is handled by the websocket and does not require an own messageAssign unique identification number
reconnectId
andclientId
do not have to be distinct.Start the game
After this message, no new player can connect.
Inform clients of who is next
Feedback about commited request
This needs more discussion regarding if this should be several different messages and what would be the best representation of an error in json.
The game has ended:
Further possible messages