DEV Community: DDCoder23

🦀🌐 Building the Network Architecture of an Open-Source MMORPG with Rust

DDCoder23 — Sat, 12 Sep 2026 16:34:46 +0000

🦀🌐 Building the Network Architecture of an Open-Source MMORPG with Rust

When building a multiplayer game, one of the first systems that has to become reliable is the network layer.

For The Last Signal Online, an open-source post-apocalyptic MMORPG I'm building, the server is written in Rust and communicates with clients through a custom TCP protocol.

The current networking layer is still under development, but it already has several important components:

a TCP server built with Tokio
asynchronous client handling
a custom binary packet format
packet parsing and validation
packet routing
authentication and account management
SQLite integration
session management
periodic ban verification
structured client logging

This article explains how the current architecture works and what I am working toward next.

🏗️ Current Architecture

The networking code is organized into five main modules:

server_rust/src/network/

├── packet.rs
├── client.rs
├── server.rs
├── handler.rs
└── parser.rs

Each module currently has a specific responsibility.

                    ┌─────────────────────┐
                    │      TCP Client      │
                    └──────────┬──────────┘
                               │
                               │ TCP
                               ▼
                    ┌─────────────────────┐
                    │       Server        │
                    │    TcpListener      │
                    └──────────┬──────────┘
                               │
                     creates Client
                               │
                               ▼
                    ┌─────────────────────┐
                    │       Client        │
                    │  session + socket   │
                    └──────────┬──────────┘
                               │
                         receive_packet()
                               │
                               ▼
                    ┌─────────────────────┐
                    │       Packet        │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   PacketHandler     │
                    └──────────┬──────────┘
                               │
             ┌─────────────────┼──────────────────┐
             ▼                 ▼                  ▼
          Parser            SQLite             Response

The goal is to keep the low-level TCP handling separate from packet processing and application logic.

🚀 1. The TCP Server

The entry point for incoming network connections is the Server structure.

It contains:

pub struct Server {
    listener: TcpListener,
    database: DatabaseManager,
}

The server creates a Tokio TcpListener and binds it to the configured address.

Once started, it continuously waits for incoming connections:

loop {
    match self.listener.accept().await {
        Ok((stream, address)) => {
            // ...
        }

        Err(e) => {
            // ...
        }
    }
}

When a client connects, the server obtains:

the TCP stream
the client's socket address

It then creates a new Client instance.

⚡ 2. One Asynchronous Task per Client

The current implementation uses Tokio tasks to handle clients independently.

When a connection is accepted:

task::spawn(async move {
    let mut client = Client::new(stream, pool);
    client.run().await;
});

This means the main listener can immediately return to accepting other connections.

Conceptually:

                    TCP Listener
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Client A       Client B       Client C
          │              │              │
       Tokio task     Tokio task     Tokio task
          │              │              │
       run()           run()           run()

This is important for a multiplayer game because the server cannot block while waiting for a single player.

👤 3. The Client Session

Each connected player is represented by a Client.

The structure currently stores:

pub struct Client {
    stream: TcpStream,
    pool: SqlitePool,
    session_id: Uuid,
    client_id: Option<i64>,
    user_id: Option<String>,
    account_id: Option<i64>,
}

This gives the networking layer both the connection itself and some session state.

The session_id is generated when the Client is created:

session_id: Uuid::new_v4(),

This provides a unique identifier for the network session independently from the database user ID.

The client can also progressively acquire information during authentication:

TCP connection
      │
      ▼
Client created
      │
      ├── session_id
      ├── client_id = None
      ├── user_id = None
      └── account_id = None
             │
             │ login/signup
             ▼
       session becomes
       associated with
       a user

🔄 4. The Client Event Loop

Once a client is created, Client::run() becomes responsible for the connection.

The interesting part is the use of:

tokio::select!

The client is currently waiting for two kinds of events:

an incoming network packet
a periodic ban-check timer

Conceptually:

                 Client::run()
                      │
                 tokio::select!
                 /            \
                /              \
       Network packet       Ban timer
             │                  │
             ▼                  ▼
      receive_packet()      get_ban_info()
             │                  │
             ▼                  ▼
      PacketHandler          BAN packet
             │                  │
             ▼                  ▼
       Response             disconnect

This allows the connection to remain responsive while the server performs periodic session checks.

📦 5. The Packet Format

The protocol currently uses a small custom binary framing format.

Every packet contains:

┌───────────────────────────┐
│ Packet size   │ 4 bytes   │
├───────────────────────────┤
│ Packet type   │ 2 bytes   │
├───────────────────────────┤
│ Payload       │ variable  │
└───────────────────────────┘

The packet size is encoded as a big-endian u32.

The packet type is encoded as a big-endian u16.

The remaining bytes are the payload.

For example:

[ 4-byte size ]
[ 2-byte type ]
[ payload...  ]

This framing allows the receiver to know exactly how many bytes belong to the current packet before processing it.

🧩 6. Packet Types

The current protocol defines several packet types:

pub enum PacketType {
    Ping = 1,
    Login = 2,
    Chat = 3,
    Move = 4,
    Log = 5,
    SignUp = 6,
    LoginResponse = 7,
    SignUpResponse = 8,
    BAN = 9,
}

The protocol therefore already covers several fundamental systems:

Packet	Current purpose
`Ping`	Connection/liveness test
`Login`	Authentication
`Chat`	Chat messages
`Move`	Player movement
`Log`	Client-side logging
`SignUp`	Account creation
`LoginResponse`	Server login response
`SignUpResponse`	Server signup response
`BAN`	Server-side ban notification

The conversion between the numeric protocol value and the Rust enum is handled by PacketType::from_u16().

Unknown packet types are rejected.

🛡️ 7. Packet Size Validation

The server currently defines:

pub const MAX_PACKET_SIZE: usize = 10 * 1024 * 1024;

Both sending and receiving enforce this maximum.

A packet smaller than the two bytes required for the packet type is also rejected.

This gives the current framing layer some basic protection against malformed or unexpectedly large frames.

The receiver follows this process:

Read 4 bytes
    │
    ▼
Decode packet size
    │
    ├── size < 2 ───────► reject
    │
    ├── size > 10 MiB ──► reject
    │
    ▼
Read exactly `size` bytes
    │
    ▼
Read packet type
    │
    ├── unknown ────────► reject
    │
    ▼
Extract payload

The use of read_exact() is particularly useful here because the server explicitly requests the number of bytes required for the current frame.

🔍 8. Parsing Login and Signup Payloads

Packets provide the outer framing.

The parser then interprets the payload for specific packet types.

For login and signup, the current payload format is:

┌────────────────────────┐
│ Email length │ 2 bytes │
├────────────────────────┤
│ Email        │ variable│
├────────────────────────┤
│ Password len │ 2 bytes │
├────────────────────────┤
│ Password     │ variable│
└────────────────────────┘

Both lengths are stored as big-endian u16 values.

The parser performs several validation steps:

checks that the length field exists
checks that the declared number of bytes exists
converts the data from UTF-8
returns an error when the payload is malformed

For example, an incomplete email is rejected before the server attempts to interpret it.

This keeps payload parsing separate from packet routing.

🧠 9. Packet Routing

Once a packet has been decoded, it is passed to:

PacketHandler::handle(...)

The handler matches on the packet type.

Conceptually:

Packet
  │
  ▼
match packet.packet_type
  │
  ├── Ping
  ├── Login
  ├── SignUp
  ├── Chat
  ├── Move
  ├── Log
  ├── BAN
  └── Responses

This is currently the main bridge between the networking layer and the rest of the server.

🏓 10. Ping / Pong

The simplest packet currently implemented is Ping.

When the server receives it, the handler creates another packet:

Packet::new(
    PacketType::Ping,
    b"PONG".to_vec(),
)

The response is then sent back through the same TCP connection.

So the current flow is:

Client
  │
  │ PING
  ▼
Server
  │
  │ PacketHandler
  ▼
  PONG
  │
  ▼
Client

This provides a simple way to test basic connectivity.

🔐 11. Authentication

The networking layer is already connected to the authentication system.

For a LOGIN packet, the handler:

parses the payload
searches for the user in SQLite
checks permanent and temporary bans
verifies the password hash
tracks failed login attempts
applies the temporary ban mechanism when necessary
checks whether the account is already connected
marks the user as connected
associates the authenticated user with the Client
returns a login response

The password verification itself is delegated to the project's password utility.

The handler therefore acts as the current integration point between:

Network protocol
       │
       ▼
Login parser
       │
       ▼
Authentication
       │
       ├── SQLite
       ├── password verification
       ├── ban system
       └── session state

🚫 12. Failed Login Attempts and Temporary Bans

The current login system also keeps track of failed attempts.

After three failed attempts, the server can create or extend a temporary ban.

There is also a banssursis mechanism in the current database logic that can modify the duration of the resulting ban.

This means authentication is not simply:

password correct → login
password wrong   → reject

There is already a larger state machine:

Login attempt
     │
     ▼
Find user
     │
     ├── not found ─────────► reject
     │
     ▼
Check bans
     │
     ├── banned ────────────► reject
     │
     ▼
Verify password
     │
     ├── incorrect
     │      │
     │      ▼
     │   increment attempts
     │      │
     │      ├── < 3 ───────► reject
     │      │
     │      └── ≥ 3 ───────► temporary ban
     │
     ▼
Check connected status
     │
     ├── already connected ─► reject
     │
     ▼
Mark CONNECTED
     │
     ▼
Associate user with Client

This is one of the areas where the network layer is already interacting heavily with persistent server state.

📝 13. Client Logging

The protocol also contains a Log packet.

The client can send structured logging information containing:

pub struct ClientLog {
    pub level: LogLevel,
    pub module: String,
    pub file: String,
    pub line: u32,
    pub message: String,
}

The server deserializes this data using serde_json.

Depending on the received level, it forwards the message to the server's logging system.

Supported levels currently include:

TRACE
DEBUG
INFO
WARNING
ERROR

This gives the client a mechanism for reporting structured diagnostic information to the server.

💬 14. Chat and Movement

The protocol already defines Chat and Move.

At the current stage, their handling is intentionally simple.

For chat:

Packet::new(
    PacketType::Chat,
    packet.payload,
)

The server currently logs the received message and sends the payload back.

Movement currently follows a similar basic path.

This is important because these packet types are part of the current protocol, but their gameplay functionality is not yet a complete MMORPG networking system.

The architecture is being built before the full gameplay layer is implemented.

⛔ 15. Server-Only Responses

The handler also explicitly rejects packets that should only originate from the server.

For example:

Client → LoginResponse
Client → SignUpResponse

are considered invalid directions.

The server logs the situation and does not generate a response.

This establishes an important concept for the protocol:

Not every packet type is valid in both directions.

As the protocol grows, this distinction will become increasingly important.

🔨 16. Signup

Account creation follows a similar path to login:

SIGN_UP packet
      │
      ▼
parse_signup_payload()
      │
      ▼
hash password
      │
      ▼
generate UUID
      │
      ▼
INSERT INTO users
      │
      ▼
associate user with Client
      │
      ▼
SIGN_UP response

The password is hashed before being stored.

The database also handles duplicate email detection.

🔌 17. Session Disconnection

When a client disconnects, the Client performs cleanup.

If the session has an authenticated user, the server updates the database:

CONNECTED
    │
    │ disconnect
    ▼
DISCONNECTED

The socket can then be shut down cleanly.

This means the network session and persistent user state are connected.

⏱️ 18. Periodic Ban Checking

One interesting part of the current architecture is that ban checking does not only happen during login.

The client starts a Tokio interval:

interval(Duration::from_secs(1))

Once a player is authenticated, the server periodically checks whether a ban has become active.

If a ban is detected:

Database
    │
    ▼
Ban detected
    │
    ▼
Create BAN packet
    │
    ▼
Send to client
    │
    ▼
Disconnect

This means an already-connected player can be removed from the server if their account becomes banned while their session is active.

🔐 19. What About Network Security?

The current networking code is intentionally still an evolving part of the project.

The code described in this article provides:

packet framing
packet size limits
packet type validation
payload validation
authentication
password hashing
ban handling
session tracking

However, this should not be interpreted as a finished secure production protocol.

For example, the networking files shown here implement TCP framing, but they do not themselves provide transport encryption such as TLS.

The project also has experimental cryptography work elsewhere, but that should not be confused with the packet framing layer described here.

Security is an ongoing area of development and review.

🧪 20. What I Want to Improve

The current architecture is a foundation rather than the final networking system.

Some of the areas I want to develop further include:

Better protocol validation

More malformed and invalid packet tests are needed.

Examples include:

invalid packet sizes
unknown packet types
truncated payloads
invalid UTF-8
invalid field lengths
unexpected packet directions

Network integration tests

I want to test the complete path:

Client
  ↓
TCP
  ↓
Server
  ↓
Parser
  ↓
Handler
  ↓
Database
  ↓
Response

rather than testing each component only in isolation.

Better packet abstractions

As the game grows, the number of packet types will increase significantly.

The protocol therefore needs to remain easy to extend without turning the handler into an unmaintainable collection of special cases.

Gameplay networking

Movement and chat are currently basic.

The future network layer will need to support much more complex game state:

player movement
world state
combat
inventories
NPCs
interactions
guilds
territories
trading
persistent world events

🗺️ The Bigger Picture

The current architecture can be summarized as:

                         THE LAST SIGNAL
                         NETWORK LAYER

                              TCP
                               │
                               ▼
                    ┌────────────────────┐
                    │      Server        │
                    │   TcpListener      │
                    └─────────┬──────────┘
                              │
                    ┌─────────┴──────────┐
                    │                    │
                    ▼                    ▼
                Client A             Client B
                    │                    │
                    ▼                    ▼
              receive_packet()    receive_packet()
                    │                    │
                    └─────────┬──────────┘
                              ▼
                       PacketHandler
                              │
          ┌──────────┬────────┼────────┬──────────┐
          ▼          ▼        ▼        ▼          ▼
        Login      Signup    Chat     Move       Log
          │          │
          ▼          ▼
       SQLite     SQLite
          │
          ▼
     Session state

The architecture is deliberately being built in layers:

TCP transport
     ↓
Packet framing
     ↓
Payload parsing
     ↓
Packet routing
     ↓
Authentication / database
     ↓
Gameplay systems

This gives the project a foundation on which the larger MMORPG systems can eventually be built.

🚀 What's Next?

The network layer is one of the areas I expect to evolve substantially as The Last Signal Online moves from prototype infrastructure toward actual multiplayer gameplay.

The next major challenges are not simply "making packets work".

They are about making the protocol:

reliable
testable
extensible
secure
efficient
easy for contributors to understand

And that is exactly where open-source development becomes interesting.

🤝 Want to Contribute?

The Last Signal Online is an open-source project, and there are several ways to contribute.

You don't need to work on gameplay to help.

Current areas include:

🦀 Rust server development
🌐 network protocol development
🧪 network testing
🐍 Python client development
🔐 security and cryptography review
⚙️ CI/CD
📚 documentation
🌍 translation
🎮 game design

If you're interested in Rust networking, multiplayer architecture, Python clients, testing, or open-source game development, there are already areas where you can get involved.

👉 👋 New Contributor? Start Here!

You can also explore the project's open issues and choose a problem that matches your interests and experience.

🦀 About The Last Signal Online

The Last Signal Online is an open-source post-apocalyptic persistent-world MMORPG built with Rust and Python.

The goal is to create a multiplayer world combining:

exploration
survival
combat
player interaction
economy
crafting
factions and territories
persistent world systems

The project is still under development, which means the architecture is evolving alongside the game itself.

That also means there are plenty of interesting problems left to solve.

👉 Explore the project on GitHub

💬 Final Thoughts

Building the network layer of an MMORPG is a very different problem from building a simple client/server application.

A Ping packet is easy.

Building a protocol that can eventually carry an entire persistent multiplayer world is much harder.

That's the challenge I'm working on with The Last Signal Online.

And I'm building it openly, one system at a time.

If Rust, networking, Python, game development, or open source interests you, feel free to take a look at the project. 🦀🐍🌐

I'm Building an Open-Source MMORPG with Rust & Python — Join the Project

DDCoder23 — Tue, 01 Sep 2026 05:04:14 +0000

I'm Building an Open-Source MMORPG in Rust and Python — Looking for Contributors

Hi everyone! 👋

I'm currently working on The Last Signal, an open-source post-apocalyptic MMORPG project.

The project is built around Rust and Python, with a strong focus on networking, server architecture, testing, and eventually building a persistent multiplayer world.

The project is still in development, so there are plenty of things to explore, improve, and build.

🎮 What is The Last Signal?

The goal is to create a multiplayer post-apocalyptic world where players can explore, interact, fight, trade, and build their own stories.

Rather than trying to build everything at once, I'm currently focusing on developing the foundations of the project: communication between the client and server, packet handling, testing, CI, and the overall architecture.

🛠️ Current technologies

🦀 Rust — server and network-related components
🐍 Python — client and tools
🌐 Client/server networking
📦 Custom network packet system
🧪 Automated testing
⚙️ GitHub Actions / CI
🗄️ Database components
🔐 Experimental cryptography — currently at a very early stage

🌐 The networking side

One of the current technical focuses is the communication between the Python client and the Rust server.

The project has its own packet system, with different packet types used for communication between the two sides.

I'm currently working on things such as:

packet creation
serialization and deserialization
handling invalid data
network error handling
testing the protocol
keeping the client and server implementations consistent

This is one of the areas where Rust contributors could have a direct impact on the project.

🔐 Cryptography is only at the beginning

The cryptography side of the project is very experimental and still at an early stage.

I'm experimenting with ideas and exploring how a cryptographic system could fit into the project.

At this point, it is not presented as production-ready or secure cryptography.

I'm actually looking for people who can challenge the design, identify weaknesses and assumptions, and help determine which approaches are worth exploring further.

Someone interested in cryptography, cryptanalysis, or security would be very welcome here.

🤝 I'm looking for contributors

I'm currently looking for people interested in contributing to an open-source project.

🦀 Rust developers

Help with areas such as:

networking
packet handling
server development
testing
error handling
architecture
performance

🐍 Python developers

Help with:

client development
testing
tools
automation
communication with the Rust server

🔐 Security / cryptography contributors

The cryptography work is still at the beginning.

Possible contributions include:

reviewing the experimental design
identifying security assumptions
finding potential weaknesses
researching alternative approaches
designing security tests
discussing the boundary between experimentation and real-world cryptography

You don't need to immediately write cryptographic code. A good technical analysis can already be a valuable contribution.

📚 Documentation contributors

Help make the project easier for new developers to understand:

architecture documentation
network protocol documentation
developer guides
English documentation

⚙️ CI/CD contributors

The project also has GitHub Actions workflows that can be improved and maintained.

Contributions involving:

testing
build workflows
automation
reliability
performance

are welcome.

🧪 Where can you start?

I've created several GitHub Issues specifically designed as entry points for contributors.

Current areas include:

🦀 Rust network protocol testing
🐍 Python client testing
📚 Client/server protocol documentation
🔐 Cryptographic design review
⚙️ CI/CD improvements
🌍 English documentation

You don't have to understand the entire project before contributing.

Small contributions are welcome.

🌱 You don't have to be an expert

If you're learning Rust or Python and want experience working on a real open-source project, you're welcome to contribute.

I'm particularly interested in people who enjoy:

learning through real projects
experimenting with technical ideas
solving difficult problems
discussing architecture
reviewing and improving existing code

You can contribute by writing code, testing, documenting, reviewing, or simply providing constructive technical feedback.

🧠 Technical feedback is welcome

The project is still young, so I'm not attached to every current implementation.

If you see a design that could be improved, I'd rather hear a well-reasoned criticism than have a bad design remain in the project.

The goal is to build something better through collaboration and discussion.

🔗 Project

GitHub:
https://github.com/DDCoder23/The-last-signal-

The repository contains the source code, documentation, and open Issues.

If the project interests you, take a look at the repository and feel free to:

open an Issue
comment on an existing Issue
suggest an improvement
submit a Pull Request

I'm looking forward to meeting people who want to learn, experiment, and build something together. 🦀🐍🚀

Thanks for reading!