DEV Community: MinBapE

[C++ 2D Arena Shooter Server #2] Packet Structure

MinBapE — Sat, 16 May 2026 08:15:57 +0000

What I did today

Designing the packet header

I defined the format for data exchanged between the client and server.

enum class PacketType : uint16_t
{
    ENTER_GAME = 1,
    // ...
};

#pragma pack(push, 1)
struct PacketHeader
{
    PacketType type;
    uint16_t size; // payload size, not including the header
};
#pragma pack(pop)

The reason I applied #pragma pack(1) to PacketHeader is that compilers insert padding between struct members by default. For example, if a uint8_t is followed by a uint32_t, the compiler may insert 3 bytes of padding in between. If the struct is transmitted over the network in that state, the layout will differ depending on the compiler settings on each side. Since packet headers must align at the byte level, I used #pragma pack(1) to eliminate the padding.

The same reasoning applies to PacketType. A plain enum has an implementation-defined size that can vary by compiler, so I explicitly fixed it to 2 bytes using enum class PacketType : uint16_t.

The resulting format is always 4 bytes for the header (2 for type, 2 for size), followed by size bytes of payload.

PacketBuffer: serialization utility

PacketBuffer is the class responsible for reading and writing packet data at the byte level.

template<typename T>
void Write(T value)
{
    static_assert(std::is_trivially_copyable_v<T>, "T must be trivially copyable");

    if constexpr (std::is_arithmetic_v<T>)
        value = detail::to_le(value);

    const char* ptr = reinterpret_cast<const char*>(&value);
    _buffer.insert(_buffer.end(), ptr, ptr + sizeof(T));
}

The static_assert(std::is_trivially_copyable_v<T>) is a compile-time safety check. If someone accidentally passes a type like std::string, which internally holds a pointer, the code will fail to compile rather than silently producing garbage bytes at runtime.

reinterpret_cast<const char*>(&value) reinterprets the address of the value as a byte pointer, giving a byte-level view of T's memory regardless of its type. The subsequent _buffer.insert copies exactly sizeof(T) bytes to the end of the buffer. This is equivalent to memcpy, but integrated directly into the std::vector.

Endian handling

When communicating over a network, there is no guarantee that both sides use the same byte order. I chose little-endian as the wire format for this project. On x86 and ARM, which are already little-endian, no actual byte swapping occurs. However, the code is written to handle big-endian environments correctly as well.

namespace detail {
    template<typename T>
    T to_le(T value) {
    #if defined(__BYTE_ORDER__) && __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
        // byte swapping only happens on big-endian machines
        ...
    #else
        return value; // no-op on x86/ARM
    #endif
    }
}

Because the branching is done with if constexpr at compile time, there is no runtime overhead.

Data models: Vector3, PlayerSnapshot, MatchSnapshot

I defined the basic game data structures for player positions and state.

struct Vector3 { float x, y, z; };

struct PlayerSnapshot {
    uint32_t playerId;
    Vector3  position;
    float    yaw, pitch;
    int32_t  hp;
    bool     isAlive;

    void Serialize(PacketBuffer& buffer) const;
    static PlayerSnapshot Deserialize(PacketBuffer& buffer);
};

PlayerSnapshot is the DTO sent to the client. It is conceptually different from a Player class that would hold authoritative server state — PlayerSnapshot exists solely to serialize that state for transmission. I defined it at this stage because I wanted to test the packet format before implementing the game loop. The fields may change once the game loop is in place.

The reason Serialize writes each Vector3 field individually rather than the whole struct at once is explained in the debugging section below.

Session packet parsing: TCP framing

The original Session::handle() was a simple echo loop that sent received data back as-is. I replaced it with actual packet parsing.

TCP is a stream protocol, which means a single recv call does not guarantee that exactly one packet has arrived. Multiple packets may arrive together, or a single packet may arrive split across multiple calls. To handle this, I accumulate received bytes into _recvBuf and process complete packets one at a time.

void Session::handle()
{
    char temp[RECV_BUFFER_SIZE];
    ssize_t bytesRead;

    while ((bytesRead = recv(_clientFd, temp, sizeof(temp), 0)) > 0)
    {
        _recvBuf.insert(_recvBuf.end(), temp, temp + bytesRead);
        processPackets();
    }
}

void Session::processPackets()
{
    constexpr size_t HEADER_SIZE = sizeof(PacketHeader);

    while (_recvBuf.size() >= HEADER_SIZE)
    {
        PacketBuffer headerBuf(_recvBuf.data(), HEADER_SIZE);
        auto rawType    = headerBuf.Read<uint16_t>();
        auto payloadLen = headerBuf.Read<uint16_t>();

        if (_recvBuf.size() < HEADER_SIZE + payloadLen)
            break; // payload not fully received yet, wait for more data

        PacketBuffer payload(_recvBuf.data() + HEADER_SIZE, payloadLen);
        _recvBuf.erase(_recvBuf.begin(), _recvBuf.begin() + HEADER_SIZE + payloadLen);

        _dispatcher.dispatch(*this, static_cast<PacketType>(rawType), payload);
    }
}

Reading the header through PacketBuffer::Read rather than a raw memcpy ensures that endian conversion is applied consistently. Reading raw bytes on a big-endian machine would produce flipped type and size values.

PacketDispatcher: packet router

PacketDispatcher looks up the handler registered for a given packet type and calls it.

class PacketDispatcher {
public:
    using Handler = std::function<void(Session&, PacketBuffer&)>;
    void registerHandler(PacketType type, Handler handler);
    void dispatch(Session& session, PacketType type, PacketBuffer& payload) const;
private:
    std::unordered_map<uint16_t, Handler> _handlers;
};

I used uint16_t as the map key instead of PacketType because the C++ standard does not explicitly require a std::hash specialization for enum class, and behavior can vary across compilers.

Handlers are owned by TcpListener and registered before the accept loop starts.

void TcpListener::registerHandlers()
{
    _dispatcher.registerHandler(PacketType::ENTER_GAME, [](Session& session, PacketBuffer& payload) {
        auto nickname = payload.ReadString(MAX_NICKNAME_LEN);
        std::cout << "[ENTER_GAME] nickname=" << nickname << std::endl;
    });
}

Session receives a PacketDispatcher& in its constructor and stores it as a member. This makes the dependency explicit: a Session cannot function without a dispatcher.

Session Manager: tracking connected clients and broadcasting to all sessions

Advice and feedback are welcome.

[Lime #2] How To Search Music

MinBapE — Mon, 11 May 2026 13:57:28 +0000

What I worked on

I designed and implemented the music search pipeline for Lime.

Music search sounds simple. Take a query, return results.

But there was more to think about than expected.

Users should be able to search for music that isn't in Lime's internal DB yet
Calling external APIs on every search request is slow and costly
If an external API fails, search shouldn't break entirely
Saving every external result directly to the DB would pollute it with data nobody cares about

To satisfy these constraints, I split search into two separate flows.

The search API returns internal DB results and cached candidates first.

External provider searches are handled asynchronously through background Jobs.

What I built

Internal DB search for Artists, Albums, and Tracks
SearchCandidate model and candidate caching
SearchJob enqueueing and ExternalSearchWorker (background processing)
External provider interface with MusicBrainz and Spotify implementations
Per-provider Rate Limiter
Merging internal DB results with external candidates, with deduplication
SearchCandidate → Artist / Album / Track Import API
ExternalMusicIds (cross-platform ID linking)
ExternalGenreTags (storing provider genre tags as-is)
Graceful degradation when providers fail

The full flow

When a user types a search query, here's what happens.

GET /search?keyword=radiohead

1. Normalize the keyword
2. Search internal DB for Artists, Albums, Tracks (parallel)
3. Query SearchCandidate cache for candidates (parallel)
4. Enqueue SearchJobs per external provider (async — does not block)
5. Merge internal results with cached candidates
6. Return response

The key point is that Step 4 does not block the response.

The user gets internal results and previously cached candidates immediately.

Background Jobs handle the external search, and the next request will see those results.

The API looks like this:

GET  /search?keyword=...
POST /search/import/{candidateId}
GET  /search/albums/{albumId}

SearchCandidate: not permanent data, just candidates

My first instinct was to save external provider results directly into the Artist, Album, and Track tables.

But thinking it through, that's a problem.

A user searching "radiohead" shouldn't cause dozens of MusicBrainz albums to become permanent Lime records.

Only music the user actually wants to review should become permanent data.

So external search results are first stored as SearchCandidate.

SearchCandidate
  - provider          (MusicBrainz, Spotify...)
  - providerEntityId  (the provider's own ID for this entity)
  - resultType        (Artist, Album, Track)
  - title
  - artistName
  - coverImageUrl
  - releaseDate
  - expiresAt         (cache TTL: 24 hours)
  - rawJson           (original response payload)

expiresAt exists because this is a cache.

After 24 hours, results are treated as stale and re-fetched on the next search.

Only when a user picks a specific candidate does it get promoted to permanent data.

SearchJob: decoupling external search from the request

If the search API called external providers directly, two problems would follow.

External APIs like MusicBrainz have rate limits (1 request per second)
A slow or failing external API would make the entire search endpoint slow

So I moved external search into SearchJob entries and let a background ExternalSearchWorker process them.

SearchJob
  - normalizedQuery  (normalized search term)
  - provider         (MusicBrainz, Spotify...)
  - resultType       (Artist, Album, Track)
  - status           (Pending, Running, Completed, Failed)
  - startedAt
  - completedAt
  - failedReason

If a Job with the same (normalizedQuery, provider, resultType) already exists, a duplicate isn't created.

ExternalSearchWorker runs every 5 seconds.

1. Fetch Pending Jobs
2. Mark each Job as Running
3. Call the corresponding provider
4. Save results as SearchCandidates
5. Mark the Job as Completed

Provider abstraction and Rate Limiter

Just like OAuth providers were abstracted behind an interface in the auth feature, external music sources follow the same pattern.

internal interface IExternalMusicProvider
{
    string ProviderName { get; }

    Task<IReadOnlyList<ExternalProviderResult>> SearchArtistsAsync(string query, CancellationToken ct);
    Task<IReadOnlyList<ExternalProviderResult>> SearchAlbumsAsync(string query, CancellationToken ct);
    Task<IReadOnlyList<ExternalProviderResult>> SearchTracksAsync(string query, CancellationToken ct);

    Task<IReadOnlyList<GenreTagResult>> LookupTagsAsync(...) => Task.FromResult(...);
    Task<ReleaseDetailResult?> LookupReleaseDetailAsync(...) => Task.FromResult<ReleaseDetailResult?>(null);
}

LookupTagsAsync and LookupReleaseDetailAsync have default implementations that return empty results.

Not every provider needs to support genre tag lookups or detailed metadata fetching.

Adding Apple Music later means creating an AppleProvider and registering it with DI.

ExternalSearchWorker looks up providers by name, so it's open for extension without modification.

Rate Limiter

MusicBrainz allows 1 request per second.

Exceed that and you get 429 responses.

ProviderRateLimiter uses a SemaphoreSlim to enforce the minimum interval between calls.

internal sealed class ProviderRateLimiter : IDisposable
{
    private readonly SemaphoreSlim _semaphore = new(1, 1);
    private readonly TimeSpan _minInterval;
    private DateTime _lastAcquired = DateTime.MinValue;

    public async Task WaitAsync(CancellationToken ct)
    {
        await _semaphore.WaitAsync(ct);
        try
        {
            var elapsed = DateTime.UtcNow - _lastAcquired;
            if (elapsed < _minInterval)
                await Task.Delay(_minInterval - elapsed, ct);

            _lastAcquired = DateTime.UtcNow;
        }
        finally
        {
            _semaphore.Release();
        }
    }
}

Each provider can have its own rate limit policy, managed by a singleton ProviderRateLimiterRegistry keyed by provider name.

Merging search results

SearchMerger combines internal DB results with SearchCandidate results.

The rules are straightforward.

1. Internal DB results go in first
2. External candidates are appended (up to 10 total per type) if not already present
3. Duplicates are detected by title + artist name

Using ExternalMusicIds for deduplication would be more precise, but title-based comparison is sufficient for now.

Internal DB results always come first.

If the same album exists in both internal and external results, only the internal one stays.

Import: promoting a candidate to permanent data

When a user selects a candidate, the client calls POST /search/import/{candidateId}.

This promotes a SearchCandidate into Lime's permanent Artist, Album, or Track records.

1. Look up the SearchCandidate by candidateId
2. Check ExternalMusicIds to see if it's already been imported
3. If yes, return the existing internal ID (prevent duplicate imports)
4. If no, find or create Artist → Album → Track in order
5. Save the platform ID in ExternalMusicIds
6. Save genre tags in ExternalGenreTags
7. If it's an album, enqueue a metadata enrichment Job

"Find or create" is the important phrase here.

The same artist or album might already exist in Lime.

The service searches by name first, and only creates a new record if nothing matches.

For example, when importing a Radiohead album, if Radiohead already exists in Lime, the import links to that existing artist rather than creating a duplicate.

ExternalMusicIds: linking platform IDs

This table connects MusicBrainz album IDs with Lime's internal Album IDs.

ExternalMusicId
  - provider          (MusicBrainz, Spotify...)
  - providerEntityId  (the provider's ID for this entity)
  - entityType        (Artist, Album, Track)
  - internalId        (Lime's internal ID)

Thanks to this table, when the same album is later fetched from Spotify, it can be linked to the existing Lime record instead of creating a duplicate.

It's the connective tissue that solves the problem: same music, different ID on every platform.

Duplicate imports are also prevented here.

If the same (provider, providerEntityId, entityType) already exists, the existing internal ID is returned as-is.

ExternalGenreTags: store genres verbatim

Lime doesn't try to define its own canonical genre taxonomy.

If MusicBrainz says "alternative rock", that's what gets stored.

If Spotify says "indie", "indie" gets stored.

ExternalGenreTag
  - entityType     (Artist, Album, Track)
  - entityId       (Lime's internal ID)
  - provider       (MusicBrainz, Spotify...)
  - tagName        (house, alternative rock, ambient...)
  - sourceLevel    (Artist, Album, Track, ReleaseGroup, Video)
  - providerEntityId
  - fetchedAt

The same (entity, provider, tagName) combination is never stored twice.

On the frontend, the plan is to display genres with their source: "MusicBrainz: alternative rock, indie".

The tricky part: when do external results become permanent?

The question I thought about the most during this work was:

When and how should external search results become permanent data?

The options I considered were:

A. Save immediately when search results come in
B. Save when the user selects something (synchronous in the search API)
C. Keep in cache only; promote to permanent data on selection

A is simple to implement, but useless data accumulates fast.

B means the search API has to wait for external API responses before it can reply.

C is what I went with.

SearchCandidate is a cache. After 24 hours it's stale.

Only when a user decides "I want to review this album" does it get promoted to permanent data.

Search stays fast. Data promotion happens after selection.

That separation is the core of this design.

A provider failure is not a search failure

MusicBrainz being unavailable shouldn't break search.

ExternalSearchWorker handles provider failures by case:

ProviderRateLimitException   -> mark Job Failed ("Rate limit exceeded")
ProviderUnavailableException -> mark Job Failed ("Provider unavailable")
any other exception          -> mark Job Failed (exception message)

All failures are recorded at the Job level.

The search response communicates this via an externalSearchStatus field.

From the user's perspective, internal DB results and cached candidates are always returned first.

If external search failed, the status is visible in the response.

Album enrichment

When an album is imported, detailed metadata — cover image, tracklist, genres — isn't fetched immediately.

Trying to fetch everything at import time would slow down that API call.

So immediately after import, an enrichment Job is enqueued for AlbumEnrichmentWorker to process.

Enrichment includes:

- Fetching cover art from Cover Art Archive
- Filling in release date
- Saving tracklist and track numbers
- Collecting genre tags per provider

Search stays fast. Details come after selection.

This same principle showed up in both search and enrichment.

Summary

This work established the core search pipeline for Lime.

Here's the full picture:

Search API
  -> Internal DB search (parallel)
  -> Cached external candidates (parallel)
  -> Enqueue external SearchJobs (async, non-blocking)
  -> Merge results + deduplicate + cap at 10 per type

Background Worker
  -> Process SearchJobs
  -> Call provider (rate-limited)
  -> Save results as SearchCandidates

Import API
  -> SearchCandidate → Artist, Album, Track
  -> Link ExternalMusicIds
  -> Save ExternalGenreTags
  -> Enqueue enrichment Job for albums

The search pipeline turned out to be more than "take a query, return results".

Thinking through response latency, API rate limits, data consistency, and provider failure handling made the flow considerably longer than expected.

Next up is wiring the review feature into this search foundation.

Leaving a rating on an imported track — that's what Lime is for.

[Lime #1] OAuth Login

MinBapE — Fri, 08 May 2026 17:52:14 +0000

Today's Work

I decided on and implemented the login flow for Lime v1.

At first, I considered supporting both OAuth login and email/password sign-up. However, building email sign-up properly would bring in many additional features, such as password hashing, email verification, and password recovery.

At this stage, I wanted to move quickly and focus on the core product. So for v1, I decided to support only Google and Discord OAuth.

In Lime v1, users do not sign up with an email and password.

They log in with a Google or Discord account, and the backend automatically creates Lime's User.

After a successful login, the backend issues a JWT Access Token and a Refresh Token for our service.

What I Built

Google OAuth login
Discord OAuth login
OAuth callback handling
Automatic Lime User creation on first login
Linking OAuth accounts to existing users
JWT Access Token issuance
Refresh Token issuance and storage
Refresh Token rotation
Logout
Handling OAuth failure and cancellation cases

Overall Flow

At first, I thought OAuth was simply about adding a "social login" button.

But the actual flow was longer than I expected.

Frontend
  -> Backend: /auth/google/start
  -> Google OAuth Page
  -> Backend: /auth/google/callback?code=...&state=...
  -> Google UserInfo API
  -> Create or find Lime User
  -> Issue JWT Access Token + Refresh Token

I designed the APIs like this.

GET  /auth/{provider}/start
GET  /auth/{provider}/callback
POST /auth/refresh
POST /auth/signout

Currently, there are two supported providers.

google
discord

Splitting It with VSA

This project is built with Vertical Slice Architecture, not around MVC Controllers.

So I did not put all authentication logic into one large controller. Instead, I split it by feature flow.

Features/Auth
  StartOAuthLogin
  HandleOAuthCallback
  RefreshSession
  SignOut
  OAuth
  Users
  Sessions
  Cookies

At first, having more files made it look more complicated.

But OAuth mixes several responsibilities.

Redirecting to the provider
Handling the callback
Finding or creating a user
Issuing tokens
Writing cookies
Handling failure cases

Putting all of this into one file would be faster at first, but it would probably become harder to read later.

So this time, I chose to split the code by flow.

Provider Abstraction

Google and Discord have similar OAuth flows, but they use different URLs and return different userinfo response formats.

So I created a common interface.

internal interface IOAuthProvider
{
    string Name { get; }
    string BuildAuthorizeUrl(string state, string redirectUri);
    Task<OAuthUserInfo> ExchangeAndFetchAsync(
        string code,
        string redirectUri,
        CancellationToken ct);
}

Each provider has its own implementation.

GoogleOAuthProvider
DiscordOAuthProvider

The callback endpoint finds and uses the correct provider based on the provider name.

If I add Apple login later, I can extend this by adding an AppleOAuthProvider and registering it in DI.

The Most Confusing Part: Cookies and State

The most confusing part of this work was cookies.

Cookies are used by the browser, so why am I creating cookies in backend OAuth code?

At first, I could not fully understand this.

But OAuth is a flow that goes through browser redirects.

Because of that, the backend needs a way to temporarily remember values between requests.

A typical example is state.

Where `state` Is Stored

When OAuth starts, the backend creates a random state value.

Then it stores this value in two places.

1. The query string of the provider authorize URL
2. A browser cookie

When the provider redirects back to the callback endpoint, it includes the state value in the query string.

The backend compares the state from the callback with the state stored in the cookie.

Same      -> Valid OAuth flow
Different -> Reject

This is used to prevent CSRF attacks.

In this implementation, I created temporary cookies for the OAuth flow.

lime_oauth_state   -> State value for CSRF protection
lime_oauth_return  -> Path to return to after successful login

Since both values do not need to live for a long time, I made them short-lived cookies and deleted them after the callback was handled.

`returnTo` Should Not Be Trusted As-Is

To send users back to the original page after a successful login, I accepted a returnTo value.

However, this value should not be trusted as-is.

For example, redirecting directly to values like these can be dangerous.

https://evil.com
//evil.com
\evil

So I did not allow external URLs and only allowed internal paths.

/dashboard
/profile

It is a small detail, but for a login feature, these details matter.

Linking Users and OAuth Accounts

Lime has its own User, and OAuth provider account information is stored in a separate table.

users
user_oauth_accounts
refresh_tokens

In OAuth login, the most reliable identifier is not the email address.

It is this combination.

provider + providerUserId

An email address can change, and whether it is verified depends on the provider.

So during login, I first look for an existing OAuth account using provider + providerUserId.

OAuth account already linked
  -> Log in as that User

OAuth account not linked
  -> If the email is verified, link it to an existing User
  -> Otherwise, create a new User

At first, it is easy to think, "If the email is the same, isn't it the same user?"

But in authentication, whether the email is verified matters.

JWT and Refresh Tokens

I did not use the OAuth provider's access token directly for Lime API authentication.

Google or Discord access tokens are meant for calling the provider's APIs.

The token used to call Lime APIs should be issued by our own service.

After a successful login, I issue two tokens.

Token	Purpose
Access Token	Authenticate Lime API requests
Refresh Token	Reissue Access Tokens

The Access Token is a JWT.

It contains minimal claims such as the user ID, email, and name, and it has a short lifetime.

The Refresh Token is a random string and is stored in the database.

However, I do not store the raw token. I only store its SHA-256 hash.

When a Refresh Token is used, the existing token is revoked and a new one is issued.

This is called refresh token rotation.

Keep the Access Token short-lived and the Refresh Token longer-lived.

But make sure the Refresh Token can be controlled through the database.

That was the basic direction for this implementation.

Storing Tokens in Cookies

In this implementation, both the Access Token and Refresh Token are stored in HttpOnly cookies.

Storing tokens in localStorage is also possible, but considering XSS, HttpOnly cookies can be a safer choice.

HttpOnly cookies cannot be read by JavaScript.

However, when using cookies, CSRF also needs to be considered.

So I explicitly configured options such as SameSite, Secure, and Path.

Also, ASP.NET Core's JWT Bearer authentication looks for the token in the Authorization header by default.

Since I store the access token in a cookie, I configured the authentication middleware to read the token from the cookie.

If this part is missed, tokens may be issued successfully, but APIs that require authentication will still treat the request as unauthenticated.

Response Format

I also defined a response format to align with the frontend.

Instead of returning a human-readable message in failure responses, I decided to return a stable code.

{
  "code": "INVALID_REFRESH_TOKEN",
  "data": null
}

The frontend can use this code to decide what message to show to the user.

This keeps localization and UI wording changes separate from the backend.

I also handled the OAuth cancellation case separately.

OAUTH_CANCELLED

When a user cancels on the provider's authentication page, it is closer to a normal failure flow than a system error.

So I separated it from ordinary missing-parameter cases.

What I Learned About Configuration

I also ran into an issue while binding configuration with IOptions<AuthOptions>.

The path the code expected was different from the actual structure in appsettings.json.

Expected by code: Auth:Jwt:SigningKey
Actual setting:   Jwt:SigningKey

Even when a value is empty, it is not always obvious at first.

This is especially important for Jwt:SigningKey, because if it is empty, the backend cannot create or validate JWTs.

One thing I learned from this is that configuration values are just as important as code.

OAuth Client ID/Secret, JWT SigningKey, and database connection settings live outside the code, but they are core parts of making the feature actually work.

Summary

With this work, the authentication foundation for Lime v1 is now in place.

What I built was not just a "Google login button."

In practice, all of these pieces had to work together.

OAuth redirect flow
state for CSRF protection
Temporary OAuth cookies
Safe returnTo handling
Fetching user information from the provider
Automatic Lime User creation
Linking OAuth accounts
JWT Access Token issuance
Refresh Token storage and rotation
Logout
Response codes aligned with the frontend

OAuth requires more surrounding design than I expected.

The successful login path may look simple, but for a real service, user mapping, token storage, cookie security, and failure cases all need to be considered together.

Next, I plan to apply this authentication middleware to protected APIs and align the frontend behavior around these response codes.

[C++ 2D Arena Shooter Server #1] Setting Up the TCP Server

MinBapE — Wed, 06 May 2026 15:14:28 +0000

Background

I started this project because I wanted to build a C++ game server as part of my portfolio. The goal is not just to make something that runs, but also to document the design decisions and the debugging process along the way. Ideally, I want to be able to answer questions like “Why did you implement it this way?” in an interview.

What I did today

Set up the directory structure

First, I separated include and src, then divided the code into network and server.

cpp-2d-arena-shooter-server/
├── include/
│   ├── common/
│   │   └── pch.h
│   ├── network/
│   │   ├── tcp_listener.h
│   │   └── session.h
│   └── server/
│       └── game_server.h
├── src/
│   ├── network/
│   │   ├── tcp_listener.cpp
│   │   └── session.cpp
│   ├── server/
│   │   └── game_server.cpp
│   └── main.cpp
└── CMakeLists.txt

Decided to start with thread-per-client

I do want to try epoll later, but for now I decided that it makes more sense to build the basic structure first. Since this is an arena shooter and each room will have at most around 16 players, the number of threads should not explode.

Also, replacing the thread-per-client model with epoll later can become a meaningful part of the commit history. From a portfolio perspective, showing that transition may actually be a good thing.

Passing the entire Session to a thread after accept

Whenever a new connection is accepted, I create a Session and move a unique_ptr into the thread.

auto session = std::make_unique<Session>(clientSocket);
std::thread(&Session::handle, std::move(session)).detach();

If I pass a raw pointer, it becomes unclear who should delete it. If I create it on the stack, it may be destroyed before the thread starts using it. So I chose unique_ptr.

By moving it into the thread, the ownership is transferred to the thread. This makes it clear in the code that “this Session is now owned by this thread.”

With this approach, when the thread finishes, the Session destructor is called automatically. Since the destructor calls disconnect(), I do not need to manage the file descriptor separately.

Session::~Session()
{
    disconnect(); // The destructor automatically closes the fd
}

Debugging notes

Called SO_REUSEADDR before socket()

_serverSocket = -1;
setsockopt(_serverSocket, ...); // fd is still -1 here
_serverSocket = socket(...);    // the socket is created after that

Every time I restarted the server, I got an “Address already in use” error. After debugging, I found that I was calling setsockopt before calling socket().

In other words, I was trying to set an option on an fd with the value -1.

Double close

When bind or listen failed, I called close and returned immediately. But I forgot to reset _serverSocket to -1, so the destructor tried to close an already closed fd again.

If the OS had already reused that fd, this could accidentally close an unrelated fd.

::close(_serverSocket);
_serverSocket = -1; // This was missing
return;

Uninitialized sockaddr_in

I had declared sockaddr_in serverAddr; without initialization, so some padding bytes contained garbage values. This was fixed by initializing it with {}.

Design the packet structure

Advice and feedback are welcome.

min-38 / cpp-2d-arena-shooter-server

cpp-2d-arena-shooter-server

View on GitHub

Docker and Kubernetes

MinBapE — Mon, 05 Jan 2026 13:35:30 +0000

Introduction

Last year, I participated in an external activity with the theme "Development of Container Monitoring Visualization Dashboard in Docker and Kubernetes Environment." To preserve the fundamental concepts of Docker and Kubernetes that I learned at that time, I'm writing this article in the way I understood them.

What is Docker?

When you run nginx on a server or execute a .sh script, from the operating system's perspective, it's just running a process. Docker is similar - running a container ultimately means executing some process. The difference isn't in how the process runs, but in the environment the process perceives. In Docker, processes operate within an isolated environment (filesystem, network, process list, etc.).

1) Why was it adopted?
The biggest advantage of Docker is that it reduces problems arising from different execution environments across servers. Even programs that build well locally often fail to run when moved to a server due to library dependency conflicts or version differences. With Docker, you can bundle applications with their required dependencies for deployment, significantly reducing trial and error from these environmental differences.

2) Definition
To properly explain Docker, it's a platform that allows you to package and run applications in units called Containers. Containers share the operating system kernel while separating the filesystem, network, and process space to run processes in an isolated environment.
Below are key terms for understanding Docker:

Image: An execution template containing files/dependencies/configurations needed for execution = Package

Container: An actually running instance based on an image = Process

Registry: A repository for storing or distributing images (e.g., Docker Hub, Amazon ECR, Google Container Registry, etc.)

In summary, Docker is a tool that creates identical execution environments as images, allowing you to run containers the same way anywhere.

3) Differences from Virtual Machines
Both VMs and Docker provide isolated execution environments, but they differ in their isolation method and weight.
Unlike Containers, VMs virtualize the entire operating system including the guest OS on top of a hypervisor. It's a structure that puts an entire OS on top of the application. This difference typically results in the following characteristics:

Resource Usage: VMs are relatively heavy as they include the OS, while Containers are lightweight.

Startup Speed: VMs require a boot process, but Containers execute closer to process execution, running much faster.

Isolation Level: VMs have stronger isolation as they're separated at the OS level, while Containers have thinner isolation boundaries compared to VMs as they share the kernel.

In summary, VMs are like virtual computers including the OS, while Containers are closer to isolated process execution that shares the kernel.
When you need a different OS environment, VMs are advantageous, and when you want to deploy programs quickly and consistently on the same kernel basis, Containers are beneficial.

What is Kubernetes?

If Docker provides the unit for creating and running Containers, Kubernetes (abbreviated as k8s) is a system for managing those Containers from an operational perspective. Its purpose is to automate problems that arise when services grow and Containers multiply (deployment, failures, scaling, networking, etc.).

1) The Inconvenience of Docker Operations
With Docker alone, running and stopping Containers isn't difficult. However, as services grow and the number of Containers increases, operational aspects become cumbersome. For example, it's not easy to consistently manage tasks like automatically recovering when a Container terminates abnormally (self-healing), scaling to multiple instances in response to traffic increases, and replacing without downtime during deployment using only Docker commands. Eventually, these operational tasks are managed by scripts or people directly, and as scale grows, management complexity rapidly increases.

2) Kubernetes Core Concepts
Kubernetes operates around several core objects:

Pod

The minimum unit for running Containers in Kubernetes

Usually manages one Container or bundles several closely related Containers together.

Deployment

An object that maintains Pods at the desired count and manages version updates (rolling update method that replaces with new versions without shutting down the service)

Service

An object that provides a fixed access point because Pods can have their IPs changed when replaced or restarted

Also serves as internal load balancing.

Node

The physical server or virtual machine where Pods actually run

Multiple nodes together form a Cluster (a unit that bundles and operates multiple servers as one).

Control Plane

The management area that stores the Cluster's state and decides which Pods to place on which Nodes

The core of Kubernetes isn't directly manipulating Containers, but managing to maintain the desired state once you declare it. If you define goals like 'n Pods should be running' or 'this Service should always be accessible', Kubernetes adjusts accordingly.

Summary

Docker is a tool that packages applications and execution environments as Images and allows you to run Containers based on them in a consistent manner.

Kubernetes is a Container orchestration system designed to automate operational issues like deployment/recovery/scaling/networking when multiple Containers come together to form a service.

Using Docker + Kubernetes together, you can create consistent execution environments with Docker and operate those environments stably and efficiently with Kubernetes. Developers only need to prepare code and images, and Kubernetes automates the rest of the operational burden. This combination has become the standard for modern cloud-native application development and operations.

const and constexpr

MinBapE — Mon, 24 Nov 2025 15:08:57 +0000

Introduction

While working on a personal project, I learned about constexpr. I understood the difference between const and constexpr. However, I wondered why constexpr is necessary when const seems sufficient. I want to share what I found in this article.

const

A keyword that promises the compiler that a value cannot be changed.
Once initialized, the value cannot be modified.

const int MAX_USERS = 100;
MAX_USERS = 200;  // Compilation error!

Characteristics

The initialization value can be known at compile time or at runtime.

int A;
std::cin >> A;
const int B = A;  // Valid
// Constant B is determined at runtime, but cannot be changed afterwards.
// The value doesn't need to be known at compile time, but once set, it cannot be changed.

It becomes more powerful when used with references and pointers.

const int* ptr1;        // Cannot change the pointed value
int* const ptr2;        // Cannot change the pointer itself
const int* const ptr3;  // Cannot change both

When const is added to a class member function, the function promises not to change the object's state.

class User {
private:
    std::string name;
    int age;
public:
    // Does not modify member variables
    std::string getName() const {
        return name;
        // age = 30;  // Error occurs
    }

    void setAge(int newAge) {
        age = newAge; // Valid
    }
};

Limitations

If a member variable is declared as mutable, it can be modified even in const member functions.
const can be forcibly removed using const_cast.

constexpr

constexpr is short for "constant expression".
Unlike const, it is a keyword that guarantees the compiler that the value is determined at compile time.
It was first introduced in C++11, and most restrictions have been lifted through version updates.

constexpr int func(int n) {
    return n * n;
}
constexpr int A = 1;        // Initialized to 1 at compile time
constexpr int B = func(2);  // Calculated to 4 at compile time
constexpr int C = func(B);  // Calculated to 16 at compile time

The critical difference from const is as follows:

int func() { 
    int value;
    std::cin >> value;
    return value;
}
const int a = func();      // Valid -> because it's determined at runtime
constexpr int b = func();  // Error occurs

Reasons to Use

Performance is improved as complex calculations can be completed at compile time through compile-time computation.
In C++, array sizes and template arguments must be compile-time constants.
Incorrect calculations can be caught before execution.
The compiler can perform more verification.

// 1. Performance improvement
constexpr int factorial(int n) {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}
constexpr int result = factorial(10);  // Zero calculation cost at runtime

// 2. Array size
constexpr int SIZE = 100;
int buffer[SIZE];  // OK

const int size = getSize();
int arr[size];  // Error in most cases

// 3. Compile-time verification
constexpr int divide(int a, int b) {
    return b == 0 ? throw "error" : a / b;
}
constexpr int x = divide(10, 0);  // Compilation error occurs

When to Use const vs constexpr?

When to use const

Use when the value can be known at runtime, such as user input, configuration values read from files.
Use const to express the intention not to modify arguments passed to a function.
Member functions that do not change the object's state should be declared as const.

When to use constexpr

C++ array sizes must be compile-time constants.
Template parameters must be determined at compile time.
Use when you want to pre-calculate complex computations.
Use in switch statement case labels, static_assert, etc.

Situation	const	constexpr
User input value	O	X
Array size	△	O
Template argument	X	O
Function parameter	O	X
Compile-time calculation	△	O

Summary

const is a promise of immutability, and constexpr is a guarantee of compile-time calculation.
const can accept runtime values, but constexpr is determined only at compile time.

TCP Variable-Length Packet Handling

MinBapE — Sat, 22 Nov 2025 13:41:43 +0000

Introduction

While developing a Socket Chatting program, I encountered a question: how should I handle messages that exceed the predefined buffer size?
This article documents my solution to this problem.

Packet Boundary Problem

// Client
send(sock, packet1, 10, 0);  // Send 10 bytes
send(sock, packet2, 20, 0);  // Send 20 bytes

// Server
char buffer[1024];
int bytes = recv(sock, buffer, 1024, 0);

What will the value of bytes be? 10? 20?
The answer is: "We can't know."

The size of data received from the client is unpredictable.
recv() can:

Receive all 30 bytes at once
Receive 10 bytes and 20 bytes separately
Split into 15 bytes twice
Even split into 7 bytes, 13 bytes, and 10 bytes

This is called the Packet Boundary Problem.

TCP is a Stream Protocol

Unlike UDP, TCP transmits data in byte units rather than message units.

send(sock, "Hello", 5, 0);
send(sock, "World", 5, 0);

When a client sends a 5-byte string twice as shown above, we might think the server will receive it twice as well. However, TCP can merge them into a single stream, resulting in receiving a 10-byte string all at once.

This happens due to the following reasons:

1. Nagle's Algorithm

A mechanism to improve TCP/IP network efficiency by reducing the number of packets to be transmitted.
Small data is buffered and sent together to prevent inefficiency where headers (40 bytes) are larger than data (1 byte).
Operating systems use this because Congestion Control across the entire network takes priority over individual program speed.
While you can reduce latency by disabling Nagle with TCP_NODELAY, this doesn't change TCP's fundamental stream-based nature, so packet boundary handling on the receiving side remains essential.

  setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

2. Network Layer

MTU (Maximum Transmission Unit): Network transmission size is typically limited to 1500 bytes.
Large data is split into multiple IP packets for transmission. Depending on network conditions, packets may not arrive in order or may be lost, but the TCP protocol reassembles them to guarantee order.
- However, during this reassembly process, data may accumulate or be split in the buffer, making data boundaries ambiguous at recv time.

3. `recv()` Call Timing

recv() returns as much data as is currently available, from a minimum of 1 byte to the maximum requested size.
The amount of data received varies depending on when recv() is called.

Solution

Header + Payload Structure

I solved this by including size information in the header.

#pragma pack(push, 1)  // Remove structure padding

struct PacketHeader
{
    PacketType type;   // 2 bytes - Packet type
    uint16_t size;     // 2 bytes - Payload size
};

struct Packet
{
    PacketHeader header;                 // 4 bytes (fixed)
    char payload[MAX_PAYLOAD_SIZE];      // Variable (actual data)
};

#pragma pack(pop)

Both server and client can first read the header to determine the payload size. The packet is wrapped with #pragma pack(push, 1) to process it once the payload is completely accumulated to that size.

Sending

void send_packet(int sockfd, const Packet& packet)
{
    // Convert to network byte order
    Packet send_packet = packet;
    send_packet.header.type = htons(packet.header.type);
    send_packet.header.size = htons(packet.header.size);

    /*
        htons() = Host TO Network Short (2-byte conversion)
        - Converts to network format regardless of current system
          -> Solves the problem of different byte ordering across CPUs
    */

    // Cast data for transmission
    const char* data = reinterpret_cast<const char*>(&send_packet);
    size_t total_size = sizeof(PacketHeader) + packet.header.size;
    size_t sent = 0;

    // Loop until all data is sent
    while (sent < total_size)
    {
        ssize_t n = send(sockfd, 
                        data + sent, 
                        total_size - sent, 
                        0);

        if (n < 0)
        {
            if (errno == EAGAIN || errno == EWOULDBLOCK)
                continue;  // Temporary error, retry

            perror("send failed");
            return;
        }

        // Add sent size
        sent += n;
    }
}

Receiving

We need to create an accumulation buffer.

struct ClientInfo {
    int fd;
    std::vector<char> recv_buffer;  // Accumulation buffer
};

This is necessary because when packets are split during transmission, they must be stored sequentially in this buffer.

bool receive_data(int sockfd)
{
    ClientInfo& client = clients[sockfd];

    char temp[4096];
    ssize_t n = recv(sockfd, temp, sizeof(temp), 0);

    if (n <= 0)
        return false;  // Connection closed or error

    // Accumulate into existing buffer
    client.recv_buffer.insert(
        client.recv_buffer.end(),
        temp,
        temp + n
    );

    return true;
}

void parse_packets(int sockfd)
{
    ClientInfo& client = clients[sockfd];

    // Continue processing while complete packets exist
    while (client.recv_buffer.size() >= sizeof(PacketHeader))
    {
        // Read header first
        PacketHeader* header =
            reinterpret_cast<PacketHeader*>(client.recv_buffer.data());

        uint16_t payload_size = ntohs(header->size);
        size_t packet_size = sizeof(PacketHeader) + payload_size;

        // Check if complete packet has arrived; if not, wait for next recv()
        if (client.recv_buffer.size() < packet_size)
            break;

        // Extract complete packet
        Packet packet;
        memcpy(&packet, client.recv_buffer.data(), packet_size);

        // Endian conversion (network → host)
        packet.header.type = ntohs(packet.header.type);
        packet.header.size = payload_size;

        // Process packet
        handle_packet(sockfd, packet);

        // Remove processed packet
        client.recv_buffer.erase(
            client.recv_buffer.begin(),
            client.recv_buffer.begin() + packet_size
        );
    }
}

Source Code

Socket Chatting Program

Mutex and Lock Guard in C++

MinBapE — Thu, 20 Nov 2025 01:53:59 +0000

Mutex (Mutual Exclusion)

Mutex is a synchronization object that controls access to shared resources in a multithreaded environment.
It is used to prevent Race Conditions that can occur when multiple threads access the same resource simultaneously.

Code Example

#include <mutex>
#include <thread>

std::mutex mtx;
int counter = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        mtx.lock();
        counter++; // Critical Section
        mtx.unlock();
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Counter: " << counter << std::endl;
    return 0;
}

Key Methods

lock()
- Locks the mutex in a blocking manner.
- If another thread has already acquired the lock, it waits until it is released.
unlock()
- Releases the acquired lock.
- Calling this from a thread that hasn't acquired the lock results in undefined behavior.
try_lock()
- Attempts to lock in a non-blocking manner, returning true on success and false immediately on failure.
- Allows performing other tasks without waiting to acquire the lock.

As shown in the example code above, the code region between lock() and unlock() (Critical Section) can only be executed by one thread at a time.
However, if an exception occurs or an early return happens before calling unlock(), a deadlock will occur.

Mutex for Special Situations

recursive_mutex
- A mutex that allows the same thread to acquire the lock multiple times.
- Must call unlock() as many times as the lock was acquired to fully release it.
timed_mutex
- A mutex that allows specifying a timeout.
- Provides try_lock_for() and try_lock_until() methods.

std::timed_mutex tmtx;

void function() {
    if (tmtx.try_lock_for(std::chrono::seconds(1))) {
        // Successfully acquired lock within 1 second
        // Critical Section
        tmtx.unlock();
    } else {
        // Timeout occurred
    }
}

shared_mutex
- Implements a Reader-Writer Lock.
- Supported from C++17.
- Multiple threads can perform read operations simultaneously, but write operations are performed exclusively.

Lock Guard

Manually managing lock() and unlock() is dangerous. The solution to this problem is the RAII (Resource Acquisition Is Initialization) pattern. It acquires resources in the constructor and releases them in the destructor, utilizing C++'s stack unwinding mechanism to ensure resources are safely released even when exceptions occur.

lock guard is one of the classes provided by the C++ standard library that helps reduce mistakes in mutex management.
When using lock guard, the mutex is automatically locked, and when the scope is exited, the lock_guard's destructor is called to automatically release the mutex.

lock_guard

The most basic RAII-based mutex wrapper.
Automatically calls lock() on construction and unlock() on destruction.
The simplest with minimal overhead.
Acquires the lock immediately upon creation.
Cannot control when the lock is released.
Cannot be copied or moved.

#include <mutex>
#include <thread>

std::mutex mtx;
int counter = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        std::lock_guard<std::mutex> lock(mtx);  // Lock on creation
        counter++;
        // Automatically unlocks when leaving scope
    }
}

void safe_function() {
    std::lock_guard<std::mutex> lock(mtx);
    if (some_condition)
        return;
    process_data();  // Unlock guaranteed even if exception occurs
}

unique_lock

Provides various features including deferred locking, condition variable integration, and ownership transfer.
Can manually call lock()/unlock().
Essential for use with condition variables like condition_variable.
Movable but not copyable.

std::mutex mtx;

void flexible_function() {
    std::unique_lock<std::mutex> lock(mtx, std::defer_lock);  // Deferred locking
    prepare_data();
    lock.lock();  // Manually lock at the needed point
    modify_shared_data();
    lock.unlock();  // Can manually release
    cleanup(); // Other tasks without lock

    // Automatically unlocks if still locked when scope ends
}

// Use with condition variables (most common case)
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
bool ready = false;

void wait_for_signal() {
    std::unique_lock<std::mutex> lock(mtx);
    cv.wait(lock, [] { return ready; });  // unique_lock required
    process_data();
}

scoped_lock

Supported from C++17.
Used to prevent deadlocks when locking multiple mutexes simultaneously.
Uses the std::lock() algorithm internally.
Identical to lock_guard for a single mutex.

std::mutex mtx1, mtx2;

// Code that can cause deadlock
void thread1() {
    std::lock_guard<std::mutex> lock1(mtx1);
    std::lock_guard<std::mutex> lock2(mtx2);  // Order issue
    // ...
}

void thread2() {
    std::lock_guard<std::mutex> lock2(mtx2);
    std::lock_guard<std::mutex> lock1(mtx1);  // Opposite order!
    // ...
}

// Prevent deadlock with scoped_lock
void safe_thread1() {
    std::scoped_lock lock(mtx1, mtx2);  // Uses deadlock avoidance algorithm
    // ...
}

void safe_thread2() {
    std::scoped_lock lock(mtx2, mtx1);  // Safe regardless of order
    // ...
}

Lock Guard is a method for safely managing mutexes using the RAII pattern.
Since locks are automatically released even in exception or early return situations, it is much safer than manually managing lock()/unlock().

In most cases, lock_guard is sufficient, and unique_lock or scoped_lock should only be used in special situations.
Proper use of these can prevent many bugs that can occur in multithreaded programming.

Smart Pointers

MinBapE — Fri, 14 Nov 2025 18:15:40 +0000

Memory Management in C/C++

Unlike languages such as Java that automatically manage memory through a Garbage Collector, C/C++ requires developers to manually allocate and deallocate memory. This means special attention must be paid to memory management. For example, C uses malloc and free to acquire and release memory, while C++ uses new and delete for the same purpose. While this characteristic allows for greater program efficiency, it also introduces risks such as memory leaks and incorrect deallocation. As a result, C/C++ programmers must always be mindful of memory usage, which is one of the key characteristics of these languages.

// 1. Memory Leak
void memoryLeakExample() {
    int* ptr = new int(42);
    // No delete -> Memory leak
}

// 2. Null Pointer Issue
void nullPointerExample() {
    int* ptr = nullptr;
    *ptr = 10;  // Crash!
}

// 3. Dangling Pointer Issue
void danglingPointerExample() {
    int* ptr = new int(42);
    delete ptr;
    *ptr = 10;  // Accessing already freed memory
}

Smart Pointer

Template classes provided in C++ for safe dynamic memory management

Smart pointers wrap raw pointers and automatically manage memory according to the RAII (Resource Acquisition Is Initialization) principle. Memory is allocated when a Smart Pointer object is created, and automatically deallocated when the destructor is called as it goes out of scope. This prevents memory leaks without developers explicitly calling delete.

Types

Unique Ptr
- Has exclusive ownership.
- Cannot be copied, only move operations are allowed.
- Has almost no overhead and performs nearly identical to raw pointers.

  void uniquePtrExample() {
      std::unique_ptr<int> ptr1 = std::make_unique<int>(42);
      // std::unique_ptr<int> ptr2 = ptr1;  // Compilation error
      std::unique_ptr<int> ptr2 = std::move(ptr1);  // Only move allowed
  }

Shared Ptr
- Multiple objects can share a single resource.
- Internally tracks the number of owners through Reference Counting.
- Memory is deallocated when the last shared_ptr is destroyed.
- Has slight performance overhead due to Reference Counting management.
- Circular references with Shared Ptr can cause memory leaks, in which case Weak Ptr should be used.

  void sharedPtrExample() {
      std::shared_ptr<int> ptr1 = std::make_shared<int>(42);
      std::shared_ptr<int> ptr2 = ptr1;  // Copy allowed
      std::cout << ptr1.use_count();  // 2
  }

Weak Ptr
- Used together with Shared Ptr, it's a pointer that only references objects without ownership.
- Does not increment Reference Counting.
- Used to resolve circular reference issues between Shared Ptr.
- lock() returns a Shared Ptr if the object is still alive, or nullptr if already destroyed.

  void weakPtrExample() {
      std::shared_ptr<int> shared = std::make_shared<int>(42);
      std::weak_ptr<int> weak = shared;  // No reference count increment

      if (auto ptr = weak.lock()) {  // Convert to shared_ptr
          std::cout << *ptr;
      }
  }

Conclusion

Smart pointers are essential tools for modern C++ programming. They help prevent common memory management issues while maintaining the performance characteristics that make C++ powerful. By understanding and using unique_ptr, shared_ptr, and weak_ptr appropriately, you can write safer and more maintainable code.

I/O Multiplexing

MinBapE — Fri, 14 Nov 2025 06:33:34 +0000

Blocking I/O

Blocking I/O is a method where the program stops and waits until an I/O operation completes.

char buffer[1024];
int n = read(socket_fd, buffer, 1024);  // Blocks here
printf("Data received: %s\n", buffer);   // Won't execute until data arrives

When the read function is called, the program waits until data arrives. This means if no data comes, it just keeps waiting indefinitely. In a single-threaded environment, if one socket is blocked, other sockets cannot be processed.

Problems with Thread per Connection

The approach of allocating one thread per client is intuitive and simple to implement, but it has several critical issues in production environments.

void handleClient(int client_fd) {
    while (true) {
        char buffer[1024];
        int n = read(client_fd, buffer, 1024);  // Blocking
        if (n > 0) {
            process(buffer);
            write(client_fd, response, size);
        }
    }
}

while (true) {
    int client_fd = accept(server_fd, ...);
    std::thread(handleClient, client_fd).detach();
}

Issues

Thread Resource Waste
- Each thread spends most of its time in an I/O waiting state (Blocking).
- Actual data processing time is often less than 1% of the entire lifecycle.
Context Switching Overhead
- As the number of threads increases, context switching frequency grows exponentially.
- Costs incurred during context switching:
- Saving/restoring register state
- Cache invalidation (increased cache misses)
- TLB (Translation Lookaside Buffer) flush
- A significant portion of CPU time is consumed by switching rather than actual work.
Memory Exhaustion
- Each thread requires independent stack memory.
- In large-scale services, memory shortage can lead to system instability.
Thread Creation/Deletion Cost
- OS-level overhead during thread creation:
- Kernel resource allocation
- Stack memory allocation and initialization
- TLS (Thread Local Storage) setup
- Scheduler registration
- Accumulated costs become significant in environments with frequent connections.
Scalability Limits
- C10K Problem: Difficulty handling more than 10,000 simultaneous connections

I/O Multiplexing

I/O Multiplexing is a technique where a single process manages multiple file descriptors simultaneously. The program monitors file descriptors to determine what type of I/O events (read, write, exceptions, etc.) have occurred and whether each file descriptor is in a ready state. Methods for implementing I/O Multiplexing include select, poll, and epoll.

How I/O Multiplexing Works

A single thread registers multiple file descriptors.
The OS kernel monitors the state of registered file descriptors.
When an I/O operation becomes possible, the application is notified.
The application performs I/O operations in a non-blocking manner only on ready file descriptors.

I/O Multiplexing Implementation Methods

1. select

Used to handle multiple files in a single thread.
Uses an array that stores up to 1024 file descriptors, and searches for target file descriptors using sequential search, causing performance degradation as the number of file descriptors increases.
Compatible with older systems, but inefficient for modern requirements.

2. poll

Unlike select, which was limited to a maximum of 1024 FDs, poll can inspect an unlimited number of file descriptors.
Still uses sequential search, so performance degrades as the number of file descriptors increases, similar to select.

3. epoll

Supported only on Linux
Supports kernel-level multiplexing to overcome select's limitations.
Manages file descriptor state in the kernel and directly notifies state changes.
- Returns the list of changed file descriptors itself rather than just the count, eliminating the need to loop through files like select and poll, making it efficient.
Calling epoll_wait eliminates the need to pass monitoring target information every time.
Two modes:
- Level-Triggered: Continuously generates events while data remains in the input buffer. Keeps notifying as long as data exists.
- Edge-Triggered: Generates an event only at the moment data enters the input buffer.

4. IOCP (I/O Completion Port)

An API that efficiently processes large volumes of non-blocking sockets in Windows environments.
Features:
- Suitable for building high-performance servers.
- Efficiently manages multiple worker threads.
- Processes through notifications when I/O operations complete.

5. kqueue

An event notification mechanism used in BSD-family operating systems like FreeBSD and macOS.
Features:
- Can monitor various events including sockets, files, and timers.
- Efficiently manages asynchronous I/O events.

epoll vs IOCP vs kqueue

Item	epoll	IOCP	kqueue
Supported OS	Linux	Windows	FreeBSD, macOS, etc.
Purpose	Large-scale network I/O processing	Asynchronous I/O processing	Event-based I/O processing
Operation Method	Event-based asynchronous I/O processing	Notification queue for completed tasks	Event registration followed by notification
Event Management	epoll_wait()	GetQueuedCompletionStatus()	kevent()
Handling Unit	File Descriptor	I/O Handle	File Descriptor, socket, etc.
Performance	Optimized for large-scale client connections	CPU core-based optimization	Efficient with diverse event management
Features	Edge-triggered, Level-triggered support Simple API Scalable	Notification from work queue after I/O completion Suitable for high-performance servers Thread pool based	File I/O, timer, and other event support Multiplexing capable Flexible structure
Advantages	High scalability Can handle many connections	Optimized CPU utilization through thread pool management Suitable for large-scale task processing	Integrated management of multiple event sources Flexible and powerful functionality

Thread Pool

MinBapE — Thu, 13 Nov 2025 18:55:51 +0000

1. The Problem with Creating Threads Per Request

Ever implemented a server that creates a new thread for every request and destroys it when done? This approach has some critical issues you might not immediately notice.

Performance Issues
Thread creation is an expensive operation. The OS has to allocate stack memory, set up execution context, and handle various initialization overhead.
Resource Exhaustion
When thousands of concurrent requests hit your server, an equal number of threads get created. Memory gets exhausted rapidly, and your system becomes unresponsive.

Thread Pool solves this elegantly.

2. Thread Pool

Thread Pool addresses these problems cleanly.

The core idea is simple:

Pre-create threads and keep them waiting
Assign work to idle threads when requests come in
Reuse threads instead of destroying them after work completes

Benefits

Performance Boost: Eliminates thread creation overhead
Resource Control: Pool size limits concurrent thread count
Stability: Thread count stays bounded even during traffic spikes

Think of it like a restaurant: instead of hiring a chef every time a customer orders, you keep N chefs on staff and distribute orders among them.

Architecture

A Thread Pool consists of 3 main components:

1. Worker Threads

N pre-created threads
Stay alive, waiting for work

2. Task Queue

Queue where pending tasks wait
Must be thread-safe (multiple threads access it)

3. Work Distribution Logic

Idle threads fetch tasks from the queue
After completing work, they loop back to check the queue

3. Code Example

Using a Thread Pool

// Create Thread Pool
size_t num_threads = std::thread::hardware_concurrency(); // CPU core count
ThreadPool pool(num_threads);

// Insert tasks into queue
for (int i = 0; i < 1000; i++) {
    pool.enqueue([i]() {
        processRequest(requests[i]);
    });
}
// Pool internally maintains only N threads while processing 1000 tasks

Basic Thread Pool Structure

class ThreadPool {
public:
    ThreadPool(size_t threads);
    ~ThreadPool();

    // Add task to queue
    template<class F>
    void enqueue(F&& f);

private:
    std::vector<std::thread> workers;           // Worker threads
    std::queue<std::function<void()>> tasks;    // Task queue

    std::mutex queue_mutex;                     // Protects queue
    std::condition_variable condition;          // Wait/notify threads
    bool stop;
};

DEV Community: MinBapE

[C++ 2D Arena Shooter Server #2] Packet Structure

What I did today

Designing the packet header

PacketBuffer: serialization utility

Endian handling

Data models: Vector3, PlayerSnapshot, MatchSnapshot

Session packet parsing: TCP framing

PacketDispatcher: packet router

Next

[Lime #2] How To Search Music

What I worked on

What I built

The full flow

SearchCandidate: not permanent data, just candidates

SearchJob: decoupling external search from the request

Provider abstraction and Rate Limiter

Rate Limiter

Merging search results

Import: promoting a candidate to permanent data

ExternalMusicIds: linking platform IDs

ExternalGenreTags: store genres verbatim

The tricky part: when do external results become permanent?

A provider failure is not a search failure

Album enrichment

Summary

[Lime #1] OAuth Login

Today's Work

What I Built

Overall Flow

Splitting It with VSA

Provider Abstraction

The Most Confusing Part: Cookies and State

Where state Is Stored

returnTo Should Not Be Trusted As-Is

Linking Users and OAuth Accounts

JWT and Refresh Tokens

Storing Tokens in Cookies

Response Format

What I Learned About Configuration

Summary

[C++ 2D Arena Shooter Server #1] Setting Up the TCP Server

Background

What I did today

Set up the directory structure

Decided to start with thread-per-client

Passing the entire Session to a thread after accept

Debugging notes

Called SO_REUSEADDR before socket()

Double close

Uninitialized sockaddr_in

Next

min-38 / cpp-2d-arena-shooter-server

cpp-2d-arena-shooter-server

Docker and Kubernetes

Introduction

What is Docker?

What is Kubernetes?

Summary

const and constexpr

Introduction

const

Characteristics

Limitations

constexpr

Reasons to Use

When to Use const vs constexpr?

When to use const

When to use constexpr

Summary

TCP Variable-Length Packet Handling

Introduction

Packet Boundary Problem

TCP is a Stream Protocol

1. Nagle's Algorithm

2. Network Layer

3. recv() Call Timing

Solution

Header + Payload Structure

Sending

Where `state` Is Stored

`returnTo` Should Not Be Trusted As-Is

3. `recv()` Call Timing