DEV Community: RYU JAEMIN

[BlindSpot] Log 04. Let's follow the SOLID principles : DIP

RYU JAEMIN — Thu, 29 Jan 2026 00:41:03 +0000

SOLID Principles

Last time, we learned about SRP, one of the SOLID principles, and refactored our code based on it. This time, we'll refactor our code based on the DIP principle.

DIP(Dependency Inversion Principle)

DIP is the principle that higher-level modules should depend on abstractions (interfaces) rather than on the concrete implementations of lower-level modules.
Failure to adhere to this principle can lead to increased dependencies between classes, such that modifying one class can lead to subsequent modifications to other classes affected by the change. Furthermore, if a test class lacks an interface, a new class must be created to perform the same functionality.
In my code, there are currently a large number of Manager/Service objects that use the Singleton pattern. If I were applying DIP, it might be easier to use something like TestAuthManager to load dummy data for testing before applying the DB later. I'll split Manager classes out to adhere to the Dependency Independent Programming (DIP) principle.

Why only Managers?

Currently, both the Manager and Service classes are singletons, using no interfaces. I'll create an interface for the Manager class here. This is because, if we later implement sign-up/login functionality, Managers will likely need to interact with the database, requiring a complete overhaul of the entire logic. If we were to use the Manager object directly instead of an interface, other code would also need to be completely overhauled. Since the Service object is responsible for the actual running logic, I decided that creating an interface was a low priority.
However, dependency injection will also be applied to service and handler classes without interface.

Let's follow the DIP principle

Making interfaces for managers

First, I made interfaces for managers(Auth,Player,Room,Session).
It contains functions from existing classes.

//IAuthManager.h

class IAuthManager {
public:
    virtual ~IAuthManager() = default;

    virtual int32_t GetPlayerIdByToken(const std::string& token) = 0;
    virtual std::string GenerateToken() = 0;
    virtual void RemoveToken(const std::string& token) = 0;
    virtual void RegisterToken(const std::string& token, int32_t playerId) = 0;
};
//... Make other interfaces the same

Inheriting an interface

I inherited the interface from the manager.
At this point, copy constructors and copy assignment operators are prevented.

AuthManager(const AuthManager&) = delete;
AuthManager& operator=(const AuthManager&) = delete;

This is because the mutex used by AuthManager cannot be copied, and even if there is no mutex, the manager object must remain intact.

//AuthManager.h
#include "../Core/Interfaces/IAuthManager.h"

class AuthManager : public IAuthManager{

public:
    AuthManager() = default;
    virtual ~AuthManager() = default;


    int32_t GetPlayerIdByToken(const std::string& token) override;
    std::string GenerateToken() override;
    void RemoveToken(const std::string& token) override;
    void RegisterToken(const std::string& token, int32_t playerId) override;
private:
    AuthManager(const AuthManager&) = delete;
    AuthManager& operator=(const AuthManager&) = delete;

    std::mutex token_mutex_;
    std::map<std::string, int32_t> tokenToPlayerId_;
    std::mutex name_mutex_;
    std::map<int32_t, std::string> playerIdToName_;
};

Injecting dependencies

Now I should inject dependencies to Service.
This should apply to all services, but I'll just use AuthService as an example.
First, I created a manager interface pointer required for private.

class AuthService {
public:

private:
    std::shared_ptr<IAuthManager> authMgr_;
    std::shared_ptr<ISessionManager> sessionMgr_;
    std::shared_ptr<IPlayerManager> playerMgr_;
};

And, And I created a constructor that includes those managers. As you can see from the code, the Service does not use static variables.

//AuthService.h
class AuthService {
public:

    AuthService(std::shared_ptr<IAuthManager> authMgr,
        std::shared_ptr<IPlayerManager> playerMgr,
        std::shared_ptr<ISessionManager> sessionMgr)
        : authMgr_(authMgr), playerMgr_(playerMgr), sessionMgr_(sessionMgr) {
    }
    void Login(std::shared_ptr<Session> session, blindspot::LoginRequest& pkt);

private:
    std::shared_ptr<IAuthManager> authMgr_;
    std::shared_ptr<ISessionManager> sessionMgr_;
    std::shared_ptr<IPlayerManager> playerMgr_;
};

The singleton pattern using the Instance() function is no longer used. Therefore, it can be used by calling the manager from within the internal function.

//Before
newPlayer->name = PlayerManager.Instance().GetPlayerNameById(playerId);
//After
newPlayer->name = playerMgr_->GetPlayerNameById(playerId);

The service has been injected with a manager, and that service will now be injected with a handler.

using PacketFunc = std::function<void(std::shared_ptr<Session>, uint8_t*, uint16_t)>;

class ServerPacketHandler {
public:
    ServerPacketHandler(std::shared_ptr<AuthService> authService, std::shared_ptr<RoomService> roomService);

    void Init();
    void HandlePacket(std::shared_ptr<Session> session, uint16_t id, uint8_t* payload, uint16_t size);

private:
    void Handle_LOGIN_REQUEST(std::shared_ptr<Session> session, blindspot::LoginRequest& pkt);
    void Handle_JOIN_ROOM_REQUEST(std::shared_ptr<Session> session, blindspot::JoinRoomRequest& pkt);
    void Handle_MAKE_ROOM_REQUEST(std::shared_ptr<Session> session, blindspot::MakeRoomRequest& pkt);

private:
    std::shared_ptr<AuthService> authService_;
    std::shared_ptr<RoomService> roomService_;

    PacketFunc packet_handlers_[UINT16_MAX];
};

Making Composition Root

Finally, we'll create a Composition Root, which is where we'll create and inject the managers, services, and handlers we'll actually use. In this project, the Server class will fulfill this role.
When the Server class's constructor is executed, it creates managers, and then creates services with those managers as constructor arguments. Finally, it creates handlers that inject those services.

//main.cpp
int main() {

    try {
        boost::asio::io_context io_context;

        std::cout << "Server starting on port "<< PORT << "..." << std::endl;
        Server s(io_context, PORT);   //Managers, services, and handlers are created and injected here.

        io_context.run(); // Start the server event loop
    }
    catch (std::exception& e) {
        std::cerr << "Exception: " << e.what() << std::endl;
    }

    return 0;
}

//Server.cpp
Server::Server(boost::asio::io_context& io_context, short port)
    : acceptor_(io_context, tcp::endpoint(tcp::v4(), port))
{
    sessionMgr_ = std::make_shared<SessionManager>();
    roomMgr_ = std::make_shared<RoomManager>();
    authMgr_ = std::make_shared<AuthManager>();
    playerMgr_ = std::make_shared<PlayerManager>();
    authService_ = std::make_shared<AuthService>(authMgr_, playerMgr_, sessionMgr_);
    roomService_ = std::make_shared<RoomService>(roomMgr_);
    packetHandler_ = std::make_shared<ServerPacketHandler>(authService_, roomService_);

    packetHandler_->Init();

    std::cout << "Server initialized on port " << port << std::endl;

    DoAccept();
}

When the main function is executed, the server constructor takes action, and the server constructor creates all managers, services, and handlers.

In Conclusion

This time, I tried refactoring the code to follow the DIP. It doesn't seem to fully adhere to the SOLID pattern yet, but I've prioritized addressing the SRP and DIP issues, which would require significant time and effort to fix later.
Next, I'll tackle the actual in-game implementation.

[BlindSpot] Log 03. Let's follow the SOLID principles : SRP

RYU JAEMIN — Tue, 27 Jan 2026 23:23:54 +0000

BlindSpot Github

SOLID Principles

SOLID principles are the five design principles of object-oriented programming.
Today I will be solving SRP and DIP issues in my code.

SRP(Single Responsibility principle)

SRP is the principle that a class(object) should have only one responsibility(function).
When this principle is not followed, maintenance problems can easily arise, such as when one function is modified, other functions that seemed unrelated stop working.
In my code, I have several classes that handle various functions.
ServerPacketHandler performs both the role of routing packets and the actual business logic(login processing, room creation logic, etc.) at the same time.
Session has a mixed role of being responsible for socket communication (Receive/Send) and a data container that holds user status information (playerId, name, room).
PlayerManager handles all the 'player' related functions, including session management, ID generation, name mapping, token management, etc.
So, I will separate all of these functions.

Let's follow the SRP principle

ServerPacketHandler.cpp

ServerPacketHandler is both receiving and processing packets.
I will change its role to only receive packets and forward them to other new service files.
I made AuthService(Login), RoomSerivce(JoinRoom, MakeRoom), GameService(In game operations to add later).

//Before
void ServerPacketHandler::Handle_MAKE_ROOM_REQUEST(std::shared_ptr<Session> session, blindspot::MakeRoomRequest& pkt) {
    if (session->room.lock()) {
        // Already in a room
        blindspot::MakeRoomResponse res;
        res.set_result(blindspot::MAKE_ALREADY_IN_ROOM);
        session->Send(blindspot::PacketID::ID_MAKE_ROOM_RESPONSE, res);
        return;
    }
    std::string title = pkt.room_name();
    int32_t maxPlayers = pkt.max_players();
    std::string password = pkt.password();
       //...omission
}

//After
void ServerPacketHandler::Handle_JOIN_ROOM_REQUEST(std::shared_ptr<Session> session, blindspot::JoinRoomRequest& pkt) {
    RoomService::JoinRoom(session, pkt);
}

Session.h

Session.h currently contains both socket communication and player information (ID, name, room). We'll separate this into a communication object (Session) and a game object (Player).
I made Player object, and insert id,name,room informations.

//Models/Player.h
class Player {
public:
    int32_t id;
    std::string name;
    std::mutex _nameLock;
    std::weak_ptr<GameRoom> room;

    void SetName(const std::string& playerName) {
        std::lock_guard<std::mutex> lock(_nameLock);
        name = playerName;
    }

    std::string GetName() {
        std::lock_guard<std::mutex> lock(_nameLock);
        return name;
    }
};
//Network/Session.h
class Session : public std::enable_shared_from_this<Session> {
public:
    Session(tcp::socket socket) : socket_(std::move(socket)) {};
    std::shared_ptr<Player> player_ ;

    std::string _sessionKey;
    //...
}

PlayerManager.h

Currently, PlayerManager manages everything from sessions, authentication, to player data.
So I'm going to break this down into PlayerManager, AuthManager, and SessionManager.

//PlayerManager.h
class PlayerManager {
    static std::atomic<int32_t> playerIdGenerator_;
    static std::mutex name_mutex_;
    static std::map<int32_t, std::string> playerIdToName_;
public:
    static PlayerManager& Instance();
    int32_t GeneratePlayerId();
    void RegisterPlayerName(int32_t playerId, const std::string& name);
    void EditPlayerName(int32_t playerId, const std::string& newName);
    std::string GetPlayerNameById(int32_t playerId);
};
//AuthManager.h
class AuthManager {
    static std::mutex token_mutex_;
    static std::map<std::string, int32_t> sessionKeyToPlayerId_;
    static std::mutex name_mutex_;
    static std::map<int32_t, std::string> playerIdToName_;
public:
    static AuthManager& Instance();
    static int32_t GetPlayerIdBySessionKey(const std::string& token);
    static std::string GenerateSessionKey();
    static void RemoveSession(const std::string& token);
    static void RegisterSession(const std::string& token, int32_t playerId);

};
//SessionManager.h
class SessionManager {
    std::mutex sessions_mutex_;
    std::set<std::shared_ptr<Session>> sessions_;

public:
    static SessionManager& Instance();
    void Add(std::shared_ptr<Session> session);
    void Remove(std::shared_ptr<Session> session);
    void Broadcast(uint16_t id, google::protobuf::Message& msg);

};

In Conclusion

Before the project grew any larger, I refactored the code to align with the SRP principle. Next time, I'll try refactoring to align with the DIP principle mentioned above.

[BlindSpot] Log 02. C# Socket Optimization : Zero-Allocation & GC Free

RYU JAEMIN — Wed, 21 Jan 2026 14:21:48 +0000

BlindSpot Github

Why Refactoring?

Since BlindSpot is an Online FPS Game, Zero-latency and Stutter-free frames are essential.
Therefore, I performed a major refactoring to minimize the garbage collection (GC) load and secure structural scalability.

1. Using a Sliding Window instead of a List

Before

//BlindSpotClient/Assets/Scripts/Network
/NetworkManager.cs

//Add received data to assemble buffer
byte[] temp = new byte[bytesRead];   // GC Overhead
Array.Copy(recvBuffer, 0, temp, 0, bytesRead);
assembleBuffer.AddRange(temp);
// Process complete packets
while (assembleBuffer.Count >= 4) 
{
      ushort packetSize = BitConverter.ToUInt16(assembleBuffer.ToArray(), 0); // GC Overhead

      if (assembleBuffer.Count < packetSize) break;

      ushort packetID = BitConverter.ToUInt16(assembleBuffer.ToArray(), 2); // GC Overhead

      byte[] payload = new byte[packetSize - 4];
      Array.Copy(assembleBuffer.ToArray(), 4, payload, 0, payload.Length);

      HandlePacket((PacketID)packetID, payload);

      assembleBuffer.RemoveRange(0, packetSize);
}

After

_currentLength += bytesRead;

int processOffset = 0;
while(_currentLength - processOffset >= 4) // Check for minimum header size
{
    //Read Size without ToArray()
    ushort packetSize = BitConverter.ToUInt16(_recvBuffer, processOffset);

    //Check packetSize validation
    if (packetSize < 4 || packetSize > Buffersize)
    {
        Debug.LogError($"[Client] Invalid Packet Size: {packetSize}");
        // Modify to reconnect logic
        CloseConnection();
        return;
    }

    if(_currentLength - processOffset >= packetSize) // Check if full packet is received
    {
        ushort packetId = BitConverter.ToUInt16(_recvBuffer, processOffset + 2);
        byte[] payload = new byte[packetSize - 4]; //payload array
        Array.Copy(_recvBuffer, processOffset + 4, payload, 0, payload.Length);
        HandlePacket((PacketID)packetId, payload);
        processOffset += packetSize; // Go to next packet
    }
    else
    {
        break; // Wait for more data
    }
}
if(processOffset > 0)
{
    int remaining = _currentLength - processOffset;
    if (remaining > 0)
    {
        Buffer.BlockCopy(_recvBuffer, processOffset, _recvBuffer, 0, remaining);
    }
    _currentLength = remaining;
}

This code reuses only one byte[] array of fixed size (8KB) and moves only the index (Offset).

2. Producer-Consumer Pattern with ConcurrentQueue

The callback function (OnReceiveData) connected to Socket.BeginRead in C# was executed on a thread other than Unity's main thread.
Accessing Unity's Transform or UI within this callback will cause a crash.

//BlindSpotClient/Assets/Scripts/Network
/NetworkManager.cs

// Network Thread
private void HandlePacket(PacketID id, byte[] payload) {
    // Insert safely without lock
    _packetQueue.Enqueue(new PacketMessage(id, payload));
}

// Main Thread (Unity Update)
void Update() {
    // Take it out of the queue and process it
    while (_packetQueue.TryDequeue(out PacketMessage packet))
{
    try
    {
        ProcessPacket(packet);
    }
    catch (Exception e)
    {
        Debug.LogError($"[Client] Packet Processing Error: {e.Message}");
    }
}
}

To use a general Queue, you need to lock it, which can cause performance degradation in case of thread contention.
ConcurrentQueue uses a lock-free algorithm internally to safely transfer data without bottlenecks even in a multi-threaded environment.

3. Remove switch-case

Switch-case is fast when there are only a few packet types, but as the game grows to 100 or 200 packets, the code becomes longer and less readable. Furthermore, branch prediction errors can cause a slight performance degradation.

//BlindSpotClient/Assets/Scripts/Network
/NetworkManager.cs
private Action<byte[]>[] _packetHandlers = new Action<byte[]>[MaxPacketID];

private void RegisterHandlers()
{
    _packetHandlers[(int)PacketID.IdLoginResponse] = HandleLoginResponse;
    _packetHandlers[(int)PacketID.IdJoinRoomResponse] = HandleJoinRoomResponse;
    _packetHandlers[(int)PacketID.IdMakeRoomResponse] = HandleMakeRoomResponse;
}

private void ProcessPacket(PacketMessage packet)
{
    int id = (int)packet.Id;
    if (id >= 0 && id < _packetHandlers.Length && _packetHandlers[id] != null)
    {
        _packetHandlers[id](packet.Payload, packet.Size); 
    }
}

The time complexity for packet processing has been reduced from O(N) (worst case) or O(log N) to constant time O(1).
Furthermore, the structure adheres to the Open-Closed Principle (OCP) because adding a new packet does not require modifying the existing logic (ProcessPacket).

4. Use ArrayPool in Sliding Window

In the code of sliding window, it uses new byte[] for payload.
Creating an array every time a packet is received triggers the Garbage Collector.
So I decided to use ArrayPool
Previous: byte[] payload = new byte[size];
Changed: byte[] payload = ArrayPool.Shared.Rent(size);

But ArrayPool lends arrays in power-of-two sizes for performance.
Therefore, if we trust payload.Length and try to parse Protobuf as is, we will end up reading the previous data (garbage data) that was left behind, which will result in an error.
So, I added a size variable to the PacketMessage structure, and made the handler recognize and process only up to size as payload.

ushort packetId = BitConverter.ToUInt16(_recvBuffer, processOffset + 2);
int payloadSize = packetSize - 4;
byte[] payload = ArrayPool<byte>.Shared.Rent(packetSize - 4);
Array.Copy(_recvBuffer, processOffset + 4, payload, 0, payloadSize);
HandlePacket((PacketID)packetId, payloadSize, payload);
processOffset += packetSize; // Go to next packet

//...

void HandleLoginResponse(byte[] payload,int size)
{
    CodedInputStream stream = new CodedInputStream(payload, 0, size);
    LoginResponse pkt = LoginResponse.Parser.ParseFrom(stream);
    Debug.Log($"[Server] Login Result: {pkt.Success}, Msg: {pkt.Message}");
    Debug.Log($"Session ID: {pkt.SessionKey}, PlayerId: {pkt.PlayerId}");
}

ArrayPools must be returned to the pool after use to avoid memory leaks. A finally block is used to ensure they are returned unconditionally, even if an exception occurs.

void Update()
{
    while (_packetQueue.TryDequeue(out PacketMessage packet))
    {
        try
        {
            ProcessPacket(packet);
        }
        catch (Exception e)
        {
            Debug.LogError($"[Client] Packet Processing Error: {e.Message}");
        }
        finally
        {
            if(packet.Payload != null) 
                ArrayPool<byte>.Shared.Return(packet.Payload);
        }
    }
}

In conclusion..

Of course, this code isn't completely Zero-Allocated.
However, by using ArrayPool to eliminate byte[] allocation/deallocation on every packet received, it addresses memory fragmentation and bulk allocation, which are major causes of GC spikes

[BlindSpot] Log 01. Designing a Game Server Architecture with C++ and Unity

RYU JAEMIN — Tue, 20 Jan 2026 14:26:14 +0000

BlindSpot Github

What is the 'BlindSpot'?

BlindSpot is the 3:3 top view shooting online game I'm developing.
github : https://github.com/ryujm1828/BlindSpot

Whole system architecture

BlindSpot's client and server operate independently and communicate via an efficient binary protocol.

Server: C++ (asynchronous I/O based Boost.Asio)
Client: Unity (C#)
Protocol: Google Protocol Buffers (Protobuf)
IDE : Visual Studio 2026

Why C++ and Unity?

In real-time multiplayer games, the performance of server is directly connected to user experience.
I chose C++ for server to handle a lot of packets without delay, and provide stable concurrency.
I choce Unity for client, because I've used it before, and this project won't be high quality graphics.

Features

1.Efficient Packet Processing

Using protobuf

syntax = "proto3";
package blindspot;

enum PacketID {
    ID_NONE = 0;
    ID_LOGIN_REQUEST = 1;
    ID_LOGIN_RESPONSE = 2;
    ID_JOIN_ROOM_REQUEST = 3;
    ID_JOIN_ROOM_RESPONSE = 4;
    ID_MAKE_ROOM_REQUEST = 5;
    ID_MAKE_ROOM_RESPONSE = 6;
}
message LoginRequest {
  string name = 1;
  string session_key = 2;  
}

With this code, I prevent human error by automatically generating communication specifications between C++ servers and C# clients with a single .proto file.

How it works

Server -> Client

//BlindSpotServer/Network/Session.h
struct PacketHeader {
    uint16_t length;
    uint16_t id;
};
//...
void Send(uint16_t id, google::protobuf::Message& msg) {
        std::string payload;
        msg.SerializeToString(&payload);

        uint16_t header_size = sizeof(PacketHeader);
        uint16_t payload_size = static_cast<uint16_t>(payload.size());
        uint16_t total_size = header_size + payload_size;

        auto send_buffer = std::make_shared<std::vector<uint8_t>>(total_size);

        PacketHeader* header = reinterpret_cast<PacketHeader*>(send_buffer->data());
        header->length = total_size;
        header->id = id;

        std::memcpy(send_buffer->data() + header_size, payload.data(), payload_size);

        auto self(shared_from_this());
        boost::asio::async_write(socket_, boost::asio::buffer(*send_buffer),
            [this, self, send_buffer](boost::system::error_code ec, std::size_t /*length*/) {
                if (ec) {
                    std::cout << "Send failed: " << ec.message() << std::endl;
                    PlayerManager::Instance().Remove(shared_from_this());
                }
            });
}

When server sends response to client, it first serialize the payload.
And adds a header containing the packet type identifier(Id) and packet length.
Lastly, send a packet to the client via async_write.
At this time, since the Session object including the Send function must not disappear during async_write, this is prevented through auto self(shared_from_this());

//BlindSpotClient/Assets/Scripts/Network
/NetworkManager.cs
private void OnReceiveData(IAsyncResult ar)
    {
        try
        {
            int bytesRead = stream.EndRead(ar);
            if (bytesRead <= 0)
            {
                Debug.Log("[Client] Disconnected from server.");
                CloseConnection();
                return;
            }

            //Add received data to assemble buffer
            byte[] temp = new byte[bytesRead];
            Array.Copy(recvBuffer, 0, temp, 0, bytesRead);
            assembleBuffer.AddRange(temp);

            // Process complete packets
            while (assembleBuffer.Count >= 4) 
            {
                ushort packetSize = BitConverter.ToUInt16(assembleBuffer.ToArray(), 0);

                if (assembleBuffer.Count < packetSize) break;

                ushort packetID = BitConverter.ToUInt16(assembleBuffer.ToArray(), 2);

                byte[] payload = new byte[packetSize - 4];
                Array.Copy(assembleBuffer.ToArray(), 4, payload, 0, payload.Length);

                HandlePacket((PacketID)packetID, payload);

                assembleBuffer.RemoveRange(0, packetSize);
            }

            stream.BeginRead(recvBuffer, 0, recvBuffer.Length, new AsyncCallback(OnReceiveData), null);
        }
        catch (Exception e)
        {
            Debug.LogError($"[Client] Receive Error: {e.Message}");
            CloseConnection();
        }
    }

TCP sends data as a stream.
So I had it reassemble the packets as it received the data flow in real time.
The size of the packet is found out through the header, and if the number of packets corresponding to the size is not enough, more data is received, and if the number of packets corresponding to the size is enough, the packets are assembled and then processed.
(For simplicity in this example, I used ToArray(), but it can be optimized)

Client -> Server

//BlindSpotClient/Assets/Scripts/Network
/NetworkManager.cs
    public void Send(PacketID id, IMessage packet)
    {
        if (client == null || !client.Connected) return;

        try
        {
            byte[] payload = packet.ToByteArray();
            ushort payloadSize = (ushort)payload.Length;
            ushort headerSize = 4;
            ushort totalSize = (ushort)(headerSize + payloadSize);

            byte[] sendBuffer = new byte[totalSize];

            Array.Copy(BitConverter.GetBytes(totalSize), 0, sendBuffer, 0, 2);
            Array.Copy(BitConverter.GetBytes((ushort)id), 0, sendBuffer, 2, 2);
            Array.Copy(payload, 0, sendBuffer, 4, payloadSize);

            stream.Write(sendBuffer, 0, sendBuffer.Length);
            Debug.Log($"[Client] Sent Packet ID: {id}");
        }
        catch (Exception e)
        {
            Debug.LogError($"[Client] Send Error: {e.Message}");

Make header and assemble whole packet.
And send the packet to Server with stream.Write().
It is safe now, however, depending on the server architecture, endianness must be taken into account.

//BlindSpotServer/Network/Session.h
void DoRead() {
        auto self(shared_from_this());
        // Wait for data asynchronously
        socket_.async_read_some(boost::asio::buffer(data_, max_length),
            [this, self](boost::system::error_code ec, std::size_t length) {
                if (!ec) {
                    std::cout << "[Debug] Raw Data Length: " << length << std::endl;
                    recv_buffer_.insert(recv_buffer_.end(), data_, data_ + length);

                    while (recv_buffer_.size() >= sizeof(PacketHeader)) {
                        PacketHeader* header = reinterpret_cast<PacketHeader*>(recv_buffer_.data());

                        std::cout << "[Debug] Expected Packet Length: " << header->length << std::endl;
                        std::cout << "[Debug] Current Buffer Size: " << recv_buffer_.size() << std::endl;
                        if (recv_buffer_.size() < header->length) {
                            break; // Not enough data for a full packet
                        }

                        std::cout << "[Debug] Packet ID: " << header->id << ", Length: " << header->length << std::endl;
                        // Process complete packet
                        uint16_t packet_id = header->id;
                        uint8_t* payload = recv_buffer_.data() + sizeof(PacketHeader);
                        uint16_t payload_size = header->length - sizeof(PacketHeader);

                        HandlePacket(packet_id, payload, payload_size);

                        recv_buffer_.erase(recv_buffer_.begin(), recv_buffer_.begin() + header->length);
                    }

                    DoRead(); // Wait for more data
                }
                else {
                    std::cout << "Client Disconnected." << ec.message() << std::endl;
                    PlayerManager::Instance().Remove(shared_from_this());
                }
            });

    }

Like the client, it is implemented in a way that receives data in real time and reassembles packets.

Asynchronous I/O

//BlindSpotServer/main.cpp
try {
        boost::asio::io_context io_context;

        std::cout << "Server starting on port "<< PORT << "..." << std::endl;
        Server s(io_context, PORT);

        io_context.run(); // Start the server event loop
    }

Rather than having a single thread handle a single connection, we detect OS-level asynchronous events through io_context.
This structure allows us to efficiently manage tens of thousands of connections with a small number of threads.

Memory Management

To prevent memory leaks and dangling pointers, which are the most dangerous elements in C++ servers, we actively utilized Smart Pointer(shared_ptr, unique_ptr).
The Session object inherits enable_shared_from_this to safely ensure the object's lifecycle within asynchronous handlers.

Scalability

Modifying networking code every time a new game feature is added is risky.
BlindSpot uses the Packet Handler pattern to automatically branch the logic based on the received packet ID.

Security

The server does not trust the client, and all logic is designed to operate through the session context, not the playerId sent by the client.
(If you find any vulnerabilities, please let me know.)

Challenges ahead

Now that I've implemented the ability to create and join a room, let's implement the actual player movement and attacking in the game.