- The number is in big endian for version 1, in little endian in version 2
- The protocol is binary protocol.
- For the string for the user input/output: The encoding is the unicode (utf16) + 32Bits of size header.
- For the string for datapack/file path, player pseudo, player skin: The encoding is the unicode (utf8) + 8Bits of size header.
- The monitoring of the player is heavy in bandwidth and resources, then it will not applied.
- The on demand player information return all the information and is heavy with the bandwidth, and the cache will be dirty due to the number of file to create to the player (4Billons or more), and disable the player id minimization.
The tpc/ip protocol split the packet into lot of small packet. Warning, you need recompose the query.
|Main code type (8Bits)||Sub code type (16Bits, optional)||Query number (8Bits, optional)||Packet size (for packet without fixed size)||Packet content|
- The packet size definition can:
- Packet size with: XX if for <255 message size, 00XXXX is for <64KB size, 0000XXXXXXXX if for the rest. (Interesting for raw protocol for 4x packet < 255Bytes than <64KB)
|Packet code (8Bits, first byte is true if query, else is message without need of reply)||Query number (8Bits, optional)||Packet size (32Bits for packet without fixed size)||Packet content|
Compression on upper level to prevent DDOS by flood packet with compression: 1) check if this packet is not already send like datapack list sync, 2) uncompress
The packet fixed size if max 253 to improve the performance, and greater than 253 the size header is a very few overhead In internal the 254 is existing packet without fixed size, 255 is unknown packet.
No packet can be at same time compressed and with fixed size. Message/Query is decompressed after the packet routing and control to prevent DDOS by dropping the double send (send 2 time or more the datapack list). Nothing is compressed/decompressed at message layer, to have fine compression control, compress only part of packet, do some control before uncompress
The query number can be only from 0 to 15, because can only have 16 conccurent query.
- The first byte send by server is 0x00 to say no encrypted or 0x01 to say encrypted by Ssl
- Base protocol messages
- Login protocol messages Split allowed from version 2
- Battle messages
- Inventory messages
- Others messages
- Master server messages Version 2
- Protocol messages table
- The round-trip delay time (RTD) or round-trip time (RTT) are mostly never present
- All the query with reply is identified by return code, then multiple query ca&n be send, it will never be blocking.
- Never ask the server reply because the reply is based on the random. A random list is used (and send by the server to the client), and both client and server do the calculate (minimize bandwidth, and not slow down). See the random list.
- Send the previous step do and new direction. Then the server can check all move into one direction (more fast), and the request on the network is grouped. The client when receive the other player move, put the other player at the good position, and do moving at the right direction. With this, if latency is < a ms to do a step is always invisible. And if latency < at time to do all the step into a direction, is invisible too
- All the network traffic shouldn't be instant, then latency can be added to compress the data. Very useful because this protocol have high level of compression.
- All heavy task is async to not slow down the quick task
Low or high bandwidth?
The server can be optimized in 2 mode: low bandwidth and high bandwidth. The communication way/mode will depends of this choice. You can too change the compression.
- The low bandwidth is optimized for client/server with low bandwidth and high latency (third world client, server on adsl), send a minimum of data
- The high bandwidth send more data, object drop at the end of the battle, is more secure for a large scale server
- Disable functionality allow to save bandwidth, like number of player online
The max player < 256 help to keep low bandwidth, because it identify the player with 1Byte (8Bits), no 2Bytes (16Bits). For repeated block like see the other moving player, that's can do 40% of bandwidth.
All is done to have multiple algorithm into the server, you can calculate that's by chunk of map, by map, or other way.
The choice is do of display number of player will depends of the max player. To minimize into 8Bits the number if max player < 255, else 16Bits.
The coordinates is limited to 8Bits. And map string is not transmited by map index into the map list (the map list should by sync).
The pseudo is too into UTF8, max 255 bytes. The skin path is too into UTF8, max 255 bytes, limited of 255 skin into fighter folder.