(Old) Alpha v0.2 Protocol - LSFN/Design GitHub Wiki
The protocol for Alpha 0.2 is quite different from the last one. Specifically the new features of network liveness testing and subcribable sub-messages.
==Liveness testing== The time tested method of PING-PONG will be used for liveness testing; each packet will have a field for whether the message is a PING-PONG type message. It is first the responsibility of the server to declare itself alive to its clients. To declare itself as live, the server will set a message's PING field and send a packet. It is the client's responsibility to respond to this. It will set the PONG field of a message and send it to the server. This is all in case the server / client are not communicating rapidly; in game there would be near constant communication and so PING-PONGs will rarely be sent if at all. To facilitate this, the networking of both client and server will record the time of when it last sent or received a message from the other. If the difference between the times recorded surpasses some threshold, a PING-PONG is performed. If it passes another, larger, threshold a disconnect is assumed and the connection is closed.
==Subscribable sub-messages== The subscription system in 0.1 was very rudimentary and it wasn't clear then what we actually wanted from it. Now I suggest a system where subscribing to data will basically subscribe to a sub-message in the message, e.g. subscribing to the SHIP's ship's movement will subscribe the INT to the sub-message that deliver's ship movement. If we wish to take this further we could have subscription to specific sub-sub-messages and so on down a tree based structure.
==Connecting and Disconnecting== The flaw as I see it in the 0.1 connect/disconnect protocol is that they were the same. In reality connects and disconnects are different beasts.
===Connecting=== The client connecting can be detected on the server without data transmission but ideally we want to know some stuff about the client. Therefore servers will only register clients in the game logic when they receive a proper handshake. First the client sends a handshake then the server responds, either accepting or rejecting the connection. The client and server can then send data during the handshake (including a session token used for reconnection (see below)). There is the concern that a client could stay connected to the server without performing this formal introduction, to cover this, clients will be disconnected less than 1s after joining if they don't send a handshake.
===Disconnecting=== If either of the client or the server wishes to disconnect, they first send a disconnect message and then immediately disconnect. This should be the last message sent/received along the connection. The receiver of the disconnect should immediately close their end of the connection. The disconnect message should contain no data but will be given to the game logic as a "controlled" disconnection so that the game knows the client is leaving the game for good. Alternatively an "uncontrolled" disconnection will be given to the game logic if the client had been unexpectedly disconnected (e.g as the result of a failed liveness test). The reasoning for this is that the game logic may wish to erase the data on a client leaving for good but store data for if a client might come back.
===Reconnection=== It is obviously the duty of the client to reconnect should a disconnection occur. A random session token will have been given by the server to the client that will uniquely identify the client on the server; this token is large enough to prevent guessing of the token and will prevent session stealing (as only that client and that server know the token). The client should provide this session token when connecting to the server it was disconnected from, this way the server can easily reinstate the stored client's data and it can resume where it left off. Additionally, the handshake response to the reconnect from the server should give the same session token (and ship-ID) to the client if the same game session is still in progress and should give a new session token (and new ship-ID) if it is a new game session.