Repository navigation
[Network] Protocol
The Dimension library includes its own RFC protocol (based on UDP) for packet-based communication between server/rooms and clients. It serves as a flexible foundation while excluding all specific game-related features. For full details, see the RFC documentation (rfc-53952.txt).
Note: Each packet mentioned here is documented in detail in the RFC. Be sure to review it for further clarification.
To make the Dimension library as adaptable as possible, a set of default packets is provided to handle common cases found in various games. These packets are designed to cover essential events and actions, while still allowing developers to extend functionality as needed.
For example, the ClientEvent packet can be used for a wide range of user-triggered events, such as key presses or game start actions. It includes a description field that allows for custom event types, giving developers flexibility to define their own behaviors without needing to modify the core library.
Other general-purpose packets, such as CreateEntity, MoveEntity, and DestroyEntity, support fundamental game operations. However, developers are encouraged to create additional packet types tailored to their specific game mechanics if necessary. This flexibility enables the Dimension library to integrate smoothly with different engines while maintaining a robust base of default functionalities.
As described in the RFC documentation, UDP inherently lacks acknowledgment for received packets, meaning packets can be lost or incomplete. To address this, Dimension includes an optional acknowledgment system for packets that require reliability.
Except for certain packets like Ping and HiServer—which are intended for status checking and do not need acknowledgment—most packets can include a PacketValidation mechanism. This acknowledgment ensures that important packets are confirmed received, helping reduce data loss in critical communications.
Note: Acknowledgment packets do not require further validation.
This validation process is integrated into the Dimension library, so developers do not need to implement their own validation checks at the application level. This built-in feature allows the library to maintain network robustness without requiring additional work from the user.
Here is an example connection sequence to establish connection between server & client.
As soon as the client knows the server's host and port, it sends a connection attempt packet (HiServer) to the server. Once the server receives this packet, it registers the client and sends a confirmation packet (HiClient) in return. If this packet is not received, the client retries the connection (The client is considered as timed out after 4s without establishing a connection).
Since the protocol is UDP only, packet loss is possible, so the server must ensure that the client has received the connection packet. To do this, acknowledgment packets (PacketValidation) are implemented. The server only finalizes the connection once the HiClient packet acknowledgment is received.
Here is an example communication sequence of the protocol based on RType game.
In this example, both client1 and client2 join the same room. When one of the clients initiates a request to start the game, it sends a ClientEvent to the server. In response, the server sends an UpdatePacket to each client in the room, redirecting their endpoints to the room's endpoint. This redirection enables direct communication between the room and its clients, which offloads the main server's queue, reduces potential bottlenecks, and improves the distribution and efficiency of communications across the system.
Note: All in-game content on the client side is managed by events sent to the server, allowing for custom events to be added for additional content.
At the start of the game, the server sends packets to create various entities (players, monsters, bullets, etc.) to the clients (CreateEntity) so that each client can display the game content.
Once the game is set up for all clients, the server triggers the events it receives (e.g., player movement in this example) and performs the necessary actions (sending a MoveEntity packet to update the player's position on all clients).
Previous page: Specifications
Next page: Feature Implementation