DEV Community: MinBapE

OSPF - Open Shortest Path First

MinBapE — Fri, 07 Aug 2026 04:44:18 +0000

1. OSPF Characteristics

A Link State routing protocol
Supports large networks, converges very fast
Messages are sent by multicast
An open standard, so it runs on every vendor's equipment
Uses Dijkstra's SPF (Shortest Path First) algorithm to pick the best path
Administrative Distance 110

IGP comparison

	RIP	EIGRP	OSPF
Scalability	Low, small networks and labs	Good	Good
Standard	open	Originally Cisco proprietary, now open but thin support elsewhere	open, supported everywhere
Production use	Rarely	Yes	Most common

What Link State means

Each router describes itself and its interfaces to its directly connected neighbours
That information is passed from router to router unchanged
So every router ends up with the full picture of the network: every router, its interfaces, and what they connect to
LSAs (Link State Advertisements) carry that information

2. OSPF Operations

Discover neighbours
Form adjacencies
Flood the LSDB (Link State Database)
Compute the Shortest Path
Install the best routes in the routing table
Respond to network changes

Packet types

Type	Name	Role
1	Hello	Sent and listened for on OSPF-enabled interfaces to discover neighbours and form adjacencies
2	DBD (Database Description)	Tells a neighbour which networks this router knows about
3	LSR (Link State Request)	Asks for the specific networks missing from a received DBD
4	LSU (Link State Update)	Carries the list of LSAs to be updated, used during flooding
5	LSAck	Acknowledges received LSAs

An LSA is not a packet type. It's the content carried inside an LSU.

OSPF uses IP protocol number 89 (6 = TCP, 17 = UDP).

3. Basic Configuration

Process ID

R1(config)#router ospf 1

Locally significant only. It does not have to match the neighbour to form an adjacency
Each instance has its own LSDB. Splitting one router across processes means routes won't cross between them
In practice only one process is ever used

The network command

R1(config-router)#network 10.0.0.0 0.0.255.255 area 0

It means three things.

Find interfaces with an IP address inside this range
Enable OSPF on them (send and listen for Hellos, peer with adjacent OSPF routers)
Advertise the network and mask configured on those interfaces

The wildcard mask is the inverse of a subnet mask. Subtract each octet from 255 (255.255.0.0 = 0.0.255.255, 255.255.255.252 = 0.0.0.3)
It does not fall back to the classful boundary. Omit the wildcard mask and you get % Incomplete command.
What gets advertised is the actual subnet on the interface, not the range typed in the network command

Verification

Command	What it shows
`show run \	section ospf`
`show ip protocols`	Router ID, area count, advertised networks, AD
`show ip ospf interface brief`	Per-interface area, cost, state, neighbour count
`show ip ospf neighbor`	Neighbour ID, priority, state, dead time
`show ip ospf database`	The LSDB
`show ip route`	`O` = OSPF, `O IA` = inter area, `O E2` = external

4. Router ID

A 32 bit value identifying an OSPF router, written like an IP address
Selection order: manually configured > highest IP of any loopback > highest IP of any other interface
Loopbacks never go down, so the Router ID never changes
Best practice: use a loopback or set it manually

R1(config-router)#router-id 2.2.2.2
R1#clear ip ospf process

A Router ID change only takes effect after the OSPF process restarts.

5. Passive Interfaces and Default Routes

Passive interface

Stops sending Hellos out that interface. The network is still advertised
Use it on interfaces with no routers behind them (user LANs, loopbacks) to cut pointless Hellos and reduce exposure

R1(config-router)#passive-interface default
R1(config-router)#no passive-interface f0/0

Default route injection

R4(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2
R4(config)#router ospf 1
R4(config-router)#default-information originate

Other routers receive it as O*E2 0.0.0.0/0.

6. Areas

Every router holding the full picture becomes a problem on large networks. Too many routes eat router memory, and one change makes every router reconverge, costing time and CPU.

Areas are a hierarchical design that splits a large network into smaller pieces. Each router keeps full information about its own area and only summary information about others.

Two-level hierarchy: a Transit area (backbone, area 0) and regular areas
Area 0 generally holds no end users. By default all transit traffic goes through it
Small networks don't need the hierarchy, everything can sit in area 0
The area is set per interface by the network command. Both sides must be in the same area to form an adjacency

Router types

Type	Definition	Route code
Backbone Router	All OSPF interfaces in area 0	-
Normal Internal Router	All OSPF interfaces in one normal area	Same area shows as `O`
ABR (Area Border Router)	Interfaces in multiple areas	Other areas show as `O IA`
ASBR (Autonomous System Boundary Router)	Redistributes an external protocol into OSPF	External shows as `O E1` / `O E2`

ABR characteristics

Separates LSA flooding zones
Is the primary point for area address summarization
Regularly acts as the source of default routes
Maintains a separate LSDB for each connected area
Ideal design is one ABR on the backbone plus one area, with three areas as the upper limit

Manual summarization

ABRs do not summarize automatically. Without it, every route is flooded everywhere.

R2(config-router)#area 0 range 10.1.0.0 255.255.0.0
R2(config-router)#area 1 range 10.0.0.0 255.255.0.0

7. Cost Metric

OSPF picks the path with the lowest cost
Total cost = sum of the outgoing interface costs along the path
For a destination in another area, the router picks the cheapest path to the ABR, and the ABR decides from there
Set the cost the same on both ends of a link or you get asymmetric routing

Reference bandwidth

Cost = Reference Bandwidth / Interface Bandwidth

The default reference bandwidth is 100 Mbps
FastEthernet = 100/100 = 1, T1 = 100/1.544 = 64
Problem: everything at 100 Mbps or faster is cost 1. FastEthernet and 10 Gigabit rank equally
Fix: raise the reference bandwidth, and set it identically on every router

R1(config-router)#auto-cost reference-bandwidth 100000

speed vs clock rate vs bandwidth

Command	Applies to	Effect
`speed`	Ethernet	Actual physical transmission rate
`clock rate`	Serial	Actual physical transmission rate (default 1.544 Mbps)
`bandwidth`	All	No effect on physical rate. Only affects software policy: OSPF/EIGRP path selection, QoS

Manipulating the metric

Prefer ip ospf cost over bandwidth, because bandwidth affects features beyond OSPF such as QoS
A manually configured cost overrides the value derived from the bandwidth

R1(config-if)#ip ospf cost 50

8. Adjacencies

Hello packets

Sent out every OSPF-enabled interface (except passive ones)
Multicast to 224.0.0.5 (all OSPF routers)
Every 10 seconds by default, Dead Interval defaults to 4x Hello = 40 seconds

Hello contents: Router ID, Hello and Dead Intervals, Neighbors list, Area ID, Router Priority, DR and BDR addresses, Authentication Flag, Stub Area Flag

These must match for two routers to form an adjacency

Each must be in the other's Neighbor list
Hello Interval, Dead Interval
Area ID
IP subnet
Authentication Flag
Stub Area Flag

MTU is not on that list. Mismatched MTU still forms neighbours, but they won't exchange routes. Default 1500 bytes, mtu affects all packets and ip mtu only IP packets.

Neighbor states

Step	State	Meaning
1	Down	No active neighbour detected
2	INIT	A Hello was received from the neighbour
3	2-Way	Own Router ID appears in the received Hello (DR/BDR elected here on multiaccess)
4	Exstart	The higher Router ID becomes primary, roles determined
5	Exchange	DBD packets sent
6	Loading	LSRs sent and LSUs received
7	Full	Fully adjacent

9. DR and BDR

On point-to-point links a pair of routers simply forms a FULL adjacency. On a multiaccess segment like Ethernet there can be many routers, and having all of them form FULL adjacencies with each other is inefficient.

A DR (Designated Router) and BDR (Backup DR) are elected
Highest priority becomes DR, second highest becomes BDR. Default priority 1, range 0-255, higher is better
Highest Router ID breaks a tie
Priority 0 removes a router from the election
The election happens at the 2-Way stage. No election on point-to-point links

R1(config-if)#ip ospf priority 100

Restart OSPF on the interface for it to take effect.

Only the DR and BDR reach FULL with every router on the segment. The rest stay at 2-Way and never exchange routes directly
On a link state change a router multicasts an LSU to 224.0.0.6 (all designated routers), and the DR multicasts it on to 224.0.0.5 (all OSPF routers)

10. Summary

OSPF is Link State, an open standard, AD 110, IP protocol number 89, uses Dijkstra's SPF
LSAs propagate unchanged, so every router holds the full picture of its own area
Process ID is local only, Router ID should come from a loopback or be set manually
The network command takes a wildcard mask, and what's advertised is the interface's actual subnet
Cost = Reference Bandwidth / Interface Bandwidth, summed over outgoing interfaces. Everything at 100 Mbps+ is cost 1, so raise the reference bandwidth identically on every router
Adjacency must match on: Hello/Dead Intervals, Area ID, IP subnet, Authentication, Stub Flag. MTU mismatch still forms neighbours but blocks route exchange
Neighbor states: Down, INIT, 2-Way, Exstart, Exchange, Loading, Full
DR/BDR are elected on multiaccess segments only, at the 2-Way stage. Highest priority wins, then highest Router ID
224.0.0.5 for Hellos and DR reflooding, 224.0.0.6 for sending to the DR
ABRs don't summarize automatically. Use area range

Hub & Switch & Router

MinBapE — Wed, 05 Aug 2026 10:32:56 +0000

1. Hub vs Switch

Both let LAN end hosts (PCs, servers, printers) plug in over Ethernet and talk to each other. The difference is the layer they operate at and how much they know.

	Hub	Switch
Operates at	Layer 1	Layer 2 (and Layer 1)
MAC addresses	Not aware	Aware
Duplex	half-duplex only	full-duplex capable, always full in practice
Simultaneous send/receive	No, one or the other	Yes
Collision Domain	All hosts share one	Dedicated per port
Collision Detection	Required, CSMA/CD detects then retransmits	Not required
Frame handling	Floods every port except the one it came in on	Sends to the destination port only (once learned)

2. How a Switch Works

Step	Behavior
Learning	On receiving a frame, record the Source MAC from the Ethernet header against the receiving port in the MAC address table
Forwarding	If the Destination MAC is in the table, send only out that port
Flooding	If the destination is a broadcast or an unknown unicast, send out every port except the one it arrived on

There are only two flooding conditions: broadcast, or unknown unicast.

Sending only to the destination port helps both performance and security. The frame goes where it's needed, so other hosts don't spend cycles on it and never see traffic that isn't theirs. A hub does the opposite: it sprays every port, so every host has to process every frame.

3. Router

Knows the paths to the various IP subnets on the network
Sending traffic from one subnet to another always requires a router
Operates at Layer 3 (also at Layers 2 and 1, and usually aware up to Layer 7)

	Router	Switch
Aware at	Layer 3	Layer 2
Role	Routing between different networks	Switching between hosts on a LAN
Interfaces	Varied: Ethernet, Serial, ISDN, ADSL	Usually Ethernet only
Port count	Few	Many
Broadcasts	Not forwarded by default	Forwarded

Hosts in the same subnet (10.10.10.x) talk through a switch alone, but the moment another subnet (10.10.11.x) is involved a router is required.

Layer 3 Switch

Higher-end switches are Layer 3 aware and can route between IP subnets
Interfaces are still Ethernet only, and port count is higher than a router's
Typical build: a Layer 3 Switch routes between internal subnets, a router handles the WAN

A Layer 3 Switch is a switch with router functions.

4. Summary

Hub is L1, half-duplex, one collision domain, no MAC awareness → always floods
Switch is L2, full-duplex, per-port collision domains, keeps a MAC address table
Learning uses the Source MAC, forwarding uses the Destination MAC
Flooding happens on broadcast or unknown unicast (out every port but the ingress one)
Many MACs per port is fine, one MAC on many ports is not
A router is required for inter-subnet traffic. Varied interfaces, few ports, no broadcast forwarding
A Layer 3 Switch can route but has Ethernet interfaces only

OSI 7 Layer

MinBapE — Tue, 04 Aug 2026 07:40:46 +0000

1. What is the OSI 7 Layer Model?

OSI (Open Systems Interconnection) is a reference model created by ISO. A framework that standardizes how computers communicate, split into 7 layers.

Each layer provides services to the layer above it, and receives services from the layer below it.

Layer	Name	Key Info	Device
7	Application	-	-
6	Presentation	-	-
5	Session	-	-
4	Transport	TCP/UDP, Port	-
3	Network	IP Address	Router
2	Data-Link	Ethernet MAC Address	Switch
1	Physical	-	Hub

What layering gives

No need to design a technology end to end. Each party owns one layer
Open standards, so multi-vendor interoperability
A problem can be narrowed to one layer, which makes troubleshooting easier

Encapsulation

The sender adds a header at each layer going 7 down to 1 (encapsulation), the receiver strips them going 1 up to 7 (de-encapsulation).

L7   [ Data ]                                    Data
L4   [TCP][ Data ]                               Segment
L3   [IP][TCP][ Data ]                           Packet
L2   [Eth][IP][TCP][ Data ][FCS]                 Frame
L1   10110100 01011101 00101110 ...              bits

2. OSI vs TCP/IP Stack

OSI is conceptual. The stack that actually moves data on production networks is TCP/IP, developed by ARPA under the US DoD in the 1960s. TCP/IP is layered too, but collapses OSI's 7 layers into 4.

OSI Model	TCP/IP Stack	Definition
Application / Presentation / Session	Application	Represents and encodes user data, controls dialog
Transport	Transport	Supports communication between end devices across networks
Network	Internet	Logical addressing and best path determination
Data Link / Physical	Link	Controls the hardware devices and media that make up the network

PDU (Protocol Data Unit)

TCP/IP Layer	PDU
Application	Data
Transport	Segment
Internet	Packet
Link	Frame

3. Layers 7, 6, 5 (the Upper Layers)

Layer 7 Application

Provides network services to user applications
Unlike the other layers, provides services to no OSI layer above it
Verifies the availability of the communication partner
Synchronizes and agrees on error recovery procedures and data integrity control

Layer 6 Presentation

Ensures information from the sender's application layer is readable at the receiver's
Converts data formats between different encoding schemes into a common format

Layer 5 Session

Establishes, manages and terminates sessions between two hosts
Synchronizes dialog between presentation layers and manages data exchange
A web server handles many users at once, so it tracks multiple communication processes separately

4. Layer 4 Transport

The layer of TCP/UDP and port numbers. Splits data into segments, transmits and reassembles them between end devices.

Session Multiplexing: one host supports multiple sessions over a single link and manages each traffic stream separately. A server takes HTTP (80) and SMTP (25) traffic at once without the sessions mixing
Flow Control: throttles the sender so data arrives only as fast as the receiver can handle

Port numbers

The destination port identifies the upper-layer protocol (HTTP = 80, SMTP = 25)
The sender also puts a source port in the Layer 4 header
What distinguishes and tracks a session is the source and destination port pair

Sender   → Receiver   : DST 80,   SRC 1500
Receiver → Sender     : DST 1500, SRC 80     // ports swap on the reply

TCP vs UDP

	TCP	UDP
Connection	Connection oriented (3-way handshake)	Not connection oriented
Sequencing	Yes	No
Reliability	Yes (ACK + retransmit)	No (no ACK)
Flow Control	Yes	No
Header Size	20 Bytes	8 Bytes

TCP 3-way handshake.

Sender                            Receiver
   |------------- SYN ------------->|
   |<----------- SYN-ACK -----------|
   |------------- ACK ------------->|
   |===== connection established ===|

Full TCP / UDP header fields

TCP header (20 Bytes)
  Source Port 16 | Destination Port 16 | Sequence Number 32
  Acknowledgment Number 32 | Header Length 4 | Reserved 6
  Code Bits 6 | Window 16 | Checksum 16 | Urgent 16
  (+ Options 0 or 32)

UDP header (8 Bytes)
  Source Port 16 | Destination Port 16 | Length 16 | Checksum 16

Reliability needed means TCP. Real-time traffic that can't absorb TCP's overhead means UDP.

Protocol	Applications (Port)
TCP	FTP(21), SSH(22), Telnet(23), HTTP(80), HTTPS(443)
UDP	TFTP(69), SNMP(161)
Both	DNS(53)

5. Layer 3 Network

Routing and QoS. IP is the main protocol and it's connectionless, so there are no acknowledgements at Layer 3. ICMP and IPSec are also Layer 3.

The IP header is 20 bytes without options.

Field	Size	Description
TTL	8 bit	Decremented by every router, discarded at 0 (prevents infinite loops)
Protocol	8 bit	Identifies the upper-layer protocol (TCP=6, UDP=17)
Source / Destination IP	32 bit each	Ties directly to IPv4 address length
Type of Service	8 bit	QoS priority marking

Unicast / Broadcast / Multicast

Type	Destination	Behavior
Unicast	A single host	1:1. Reaching many hosts means a separate copy to each
Broadcast	All hosts in the subnet	Switches forward it, routers do not
Multicast	Interested hosts only	One stream reaches only the hosts that want it. Routers can forward it

Broadcasts not crossing a router = the router is the boundary of the broadcast domain.

Logical addressing

IP addressing is a logical addressing scheme implemented at Layer 3, used to divide a network into smaller subnets
Subnetting improves performance and security and makes troubleshooting easier
Layer 2 MAC addressing is one giant flat scheme with no hierarchy. Layer 2 has no logical separation between networks, that only happens at Layer 3
A host uses the subnet mask to check whether the destination is in the same subnet. Same subnet goes directly through the switch, different goes via the router

The addressing scheme itself (IP classes, mask math, CIDR, RFC 1918) is in a separate post.

6. Layer 2 Data-Link

Where frames are encoded into and decoded from bits. Error detection and correction for the Physical Layer can be provided here. Ethernet is the Layer 2 medium on LANs.

┌──────────┬─────────┬─────────┬──────────┬───────────────┬─────────┐
│ Preamble │ DST MAC │ SRC MAC │ Len/Type │     Data      │   FCS   │
│ 8 Bytes  │ 6 Bytes │ 6 Bytes │ 2 Bytes  │ 46~1500 Bytes │ 4 Bytes │
└──────────┴─────────┴─────────┴──────────┴───────────────┴─────────┘
                                                            trailer

Preamble: frame start synchronization
Length / Ethertype: length, or upper-layer protocol type
FCS: error detection. A trailer at the end of the frame, not part of the header

MAC address 6 Bytes = 48 bits. Data max 1500 Bytes = Ethernet's default MTU.

Some sources list the Preamble as 7 Bytes. That's IEEE 802.3 counting Preamble 7 Bytes and SFD (Start Frame Delimiter) 1 Byte separately, which adds up to the same 8 Bytes. Cisco material and Ethernet II fold the SFD into the Preamble and call it 8 Bytes.

Preamble and SFD aren't counted in the frame size. The 64 to 1518 Byte Ethernet frame runs from DST MAC through FCS: 14 + 46 + 4 = 64, 14 + 1500 + 4 = 1518.

MAC Address

	First 24 bits	Last 24 bits
Name	OUI (Organizationally Unique Identifier)	Vendor Assigned
Assigned by	IEEE	The manufacturer
Example (`00:50:56:C0:00:08`)	`00:50:56`	`C0:00:08`

The OUI identifies the manufacturer of that Ethernet port. MAC addresses are burned into the NIC and globally unique.

MAC is 48-bit, Layer 2, fixed at manufacture, flat. IP is 32-bit, Layer 3, assigned by an admin, hierarchical. Layer 2 has no logical separation between networks, that happens at Layer 3.

7. Layer 1 Physical

Puts a bit stream onto the network as electrical impulses, light or radio signals. The electrical and mechanical layer, defining cables, interface cards and physical specifications. Media are coaxial (unused now), twisted copper pair, fiber, wireless.

UTP (Unshielded Twisted Pair): most common for desktop PC to switch. RJ-45 connector, 100 m maximum
Straight-Through: end device to switch (PC to Switch, Router to Switch)
Crossover: same kind of device directly (PC to PC, Switch to Switch). Auto MDI-X handles this automatically on modern switches
Fiber: for longer distance or higher bandwidth. Single Mode is higher bandwidth and longer reach but pricier, Multi Mode is cheaper

8. Summary

OSI is a conceptual 7-layer model, TCP/IP is the 4-layer stack in use. PDUs are Data, Segment, Packet, Frame
Devices by layer: L3 Router, L2 Switch, L1 Hub
L4 distinguishes sessions by port. Reliability means TCP (20 Bytes), low latency means UDP (8 Bytes)
L3 divides networks with logical addressing. Broadcasts don't cross routers, so the router is the boundary of the broadcast domain
L2 MAC is 48-bit, flat, fixed at manufacture. L3 IP is 32-bit, hierarchical, assigned by an admin
Layers 5 to 7 are the app developer's territory, layers 1 to 4 the network engineer's

[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.

DEV Community: MinBapE

OSPF - Open Shortest Path First

1. OSPF Characteristics

2. OSPF Operations

3. Basic Configuration

4. Router ID

5. Passive Interfaces and Default Routes

6. Areas

7. Cost Metric

8. Adjacencies

9. DR and BDR

10. Summary

Hub & Switch & Router

1. Hub vs Switch

2. How a Switch Works

3. Router

4. Summary

OSI 7 Layer

1. What is the OSI 7 Layer Model?

2. OSI vs TCP/IP Stack

3. Layers 7, 6, 5 (the Upper Layers)

4. Layer 4 Transport

5. Layer 3 Network

6. Layer 2 Data-Link

7. Layer 1 Physical

8. Summary

[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

Where `state` Is Stored

`returnTo` Should Not Be Trusted As-Is

3. `recv()` Call Timing