NullpoMino Protocol 1.0

First Specification and Design Considerations

Section 1. Motivation

It is imperative that we design a protocol which is easily extensible, but which can also be backwards-compatible if need be. It also needs the ability to be heavily optimized. The current protocol is not living up to expectations.

The new protocol will rely on messages. Some will be blocking messages, that is, messages that require an answer before any other message can be sent, and some will be non-blocking, meaning they do not (in order to facilitate transport of game messages over UDP). The current protocol has a reliance on TCP which is bad for performance.

Under this protocol, it will also be possible to create a chat client which will interface with the NullpoMino server but which will not play games, for example.

Section 2. Structure of a message

Messages can be split into several parts.

The first two bytes are the opcode. Thus, in this version of the protocol, there are 65536 possible opcodes. The opcode determines the message type.

The next chunk is the size. The size is a variable length chunk; it first specifies its own size and then specifies the size of the message body that comes after it with that number of bytes. It is probably the case that no more than 2 bytes will be used for the size, but it is easily extended in case someone needs to send a file which is more than 16 KB.

If the size block is prefixed with a 0 bit, then the size block is 1 byte long. For each 1 before the first 0, another byte is used. So, 10xxxxxx in the first byte means that the size block is 2 bytes long. 110xxxxx means that it is 3 bytes long. It is easy to see how this pattern continues. Because only the first byte is used for the size of size information, it is possible to get a maximum of 9 bytes (if the first byte is 11111111), which means exactly 8 bytes of body size information since the first byte is used up. However, it is unlikely that a user will try to send a message of length 264-1, and in the event of such an occurrence the server should probably kick the user.

First byte                        Maximum size

0xxxxxxx                        27-1 = 127 B

10xxxxxx                        214-1 = 16 KB

110xxxxx                        221-1 = 2 MB

1110xxxx                        228-1 = 256 MB

…

11111110                        256-1 = 64 PB

11111111                        264-1 = 16 EB

The next block is the message body. It is expected that this will have exactly the number of bytes specified in the body size information. If this is incorrect, this message or the next message will be corrupted. The structure of the message body heavily depends on the opcode.

Section 3. Connection handshake

Upon connection, the server sends a WELCOME message to the client, detailing some server options such as minimum required protocol and game version. The client responds with CLIVER, which details the versions the client is using. The server should always use the protocol version which corresponds to the highest one the client supports. The server responds with VCHECK, which contains the protocol version, or 0 if it fails (after which the client should be disconnected).

The client can then login with a LOGIN message, or attempt to create a new account with the NEWACCT message. The server will respond with success or failure (AUTHSTAT and ACCTSTAT, respectively). Upon success, the client will ask for the server options with GETOPTS, and the server responds with SERVOPTS.

At this point the handshake is complete and the client can now use the server resources with the rest of the opcodes.