Section: Separate network layers before capturing.
Lesson 9.1 showed that one game message can arrive across two T C P, transmission control protocol, reads. A packet capture lets us inspect the bytes on the way, but its packet rows are not automatically game-message rows. We will send one distinctive lobby message, then follow its bytes in both directions.
An application message is not the same thing as an i p packet or T C P segment. Each layer has a different job:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
T C P may split one game message across several segments or combine bytes from several messages in one segment. Retransmissions can repeat packet data. The receiving application sees an ordered stream, so protocol parsing needs its own framing rule such as a length prefix or delimiter.
A socket is an operating-system object representing one endpoint. A T C P connection is identified by source address, source port, destination address, and destination port—the four-tuple used below.
Section: Follow a join request beyond loopback.
Our capture stays local. To understand the wider journey, imagine a client joining match 42 and downloading its map from assets.example. Configuration, name lookup, delivery, and game permission solve different parts of that trip.
Section: Find a destination before connecting.
On a typical IPv4 LAN, DHCP gives a device an address lease and network configuration; options can supply a router and DNS servers. It configures the device, not the remote game’s identity. DHCP and its options specify that exchange. Static configuration and other address-assignment systems are also possible.
DNS resolves a name such as assets.example to records including i p addresses. A resolver can reuse an answer until its cache lifetime expires; name resolution does not deliver the map. The client then connects to the chosen endpoint. DNS concepts explain this separate lookup.
HTTP is the web’s request/response protocol. HTTPS carries that exchange over an authenticated, encrypted connection. A CDN can serve a cached map from an edge location. A cache miss may require an origin fetch; DNS answer caching and content caching have different lifetimes. Account requests still need their own authentication and cache policy. Cloudflare’s request journey shows these boundaries.
An IPv4 lease configures the client. DNS returns an address; only the later HTTPS connection retrieves the asset from the CDN, with an origin fetch on a cache miss.
Section: Wrap the bytes across a LAN.
A LAN, or local area network, joins nearby devices through links such as Ethernet or Wi-Fi. In this example, an Ethernet frame carries an i p packet, which carries a U D P, user datagram protocol, datagram, which carries game bytes. This wrapping is encapsulation. A switch forwards link frames; a router forwards the i p packet onto another link with a new link frame. Physical signaling carries the bits on each link.
The OSI model names seven conceptual layers: application, presentation, session, transport, network, data link, and physical. The Internet’s T C P/i p model commonly groups application work, transport, Internet/i p, and link work. These models describe responsibilities, not seven mandatory headers. Our existing layer board remains useful: identify the job before assigning a name. Internet host requirements organize the protocol suite by these responsibilities.
The same game bytes are wrapped inside a U D P datagram or T C P segment, an i p packet and an Ethernet frame. A router replaces the link wrapper for the next hop. The OSI/T C P-i p mapping is conceptual, not a literal count of wire headers.
Section: Choose the delivery contract, then the application protocol.
If middle bytes are lost, T C P recovers them before exposing later bytes in its ordered stream. U D P can deliver a later datagram without the missing one; the game decides whether to replace stale state or add its own recovery. Neither transport acknowledgment proves the server accepted a purchase. T C P and U D P specify those different contracts.
T C P application messages still need framing: a lost packet changes timing, not message boundaries.
A socket is the local operating-system endpoint already introduced above. A WebSocket is a two-way framed-message protocol, useful for browser lobby chat. The RFC 6455 handshake uses HTTP/1.1 Upgrade; wss protects the exchange with TLS, Transport Layer Security, which authenticates the server and protects data in transit. HTTP/3 also has a WebSocket mapping, so an Upgrade handshake is not universal. Game authorization remains separate.
QUIC v1 runs over U D P but supplies its own reliable streams and loss recovery, using TLS 1.3 for connection security. HTTP/3 maps HTTP requests and responses onto QUIC. Loss affecting one stream need not block unrelated stream delivery, although streams share connection congestion limits. QUIC is not “unreliable HTTP,” and HTTP/3 is not a synonym for every game’s U D P protocol. The standards are QUIC v1, QUIC with TLS, and HTTP/3.
Clarification: A socket names an endpoint; WebSocket names a message protocol. QUIC builds reliable streams over U D P. An encrypted channel still needs game-specific identity and action checks.
To compare how these protocols begin, step through one conversation for each.
Section: Other names belong at other boundaries.
Publishing the map might use FTP, which separates control and data connections, or SFTP, which transfers files over encrypted SSH. SFTP is different from FTPS, FTP secured with TLS. A web server might use FastCGI to pass requests to a persistent application worker; the player’s side still uses HTTP. Web3 applications may use blockchain-backed records, but a ledger is not a replacement for sockets or real-time match transport. Likewise, Base64 only encodes bytes: an encoded login value has not thereby been encrypted.
With those boundaries separate, return to the controlled local capture. We can now ask which interface, direction, and protocol layer produced each row.
Section: Capture answers “what crossed,” not “why”.
A network trace records bytes and timing at one capture point. It does not contain the sender’s variable names, the receiver’s interpretation, or any record of which UI action caused which packet. That link comes from changing one thing at a time:
capture a quiet baseline;
perform exactly one distinctive local action;
repeat the action with one changed input;
compare both directions and several repetitions;
confirm the candidate fields in the open-source client or server.
In brief: A capture records traffic. Controlled actions and repeat comparisons connect those bytes to meaning.
Section: Build a controlled capture.
Use the course’s local Wesnoth server setup or your own toy client and server. Keep both endpoints inside the lab V M, virtual machine.
Start Wireshark, choose the loopback adapter when client and server share the machine, and begin capture before connecting.
Capturing on the wrong interface produces an empty-looking experiment. Traffic to 127.0.0.1 stays on the loopback path rather than crossing the physical Wi-Fi or Ethernet adapter.
Section: Reduce noise.
Filter by the known local port. Wireshark has two filter boxes, and each has its own syntax for the same job:
Display filter (hides rows afterwards)
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Capture filter (never records the rest)
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
A display filter can be changed at any time, because everything was recorded. A capture filter keeps the file small, but a packet it dropped cannot be recovered, so use the display filter while you are still learning what to look for.
For the Wesnoth 1.14.9 lab, keep 15000: that is wesnothd’s default listening port. Launch wesnothd.exe, choose Connect to Server in the game, and enter localhost:15000.
Perform the actions at known times, so each burst of packets can be matched to the action just before it:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
A distinctive message such as hello-17 is easier to find than “hi.”
Section: Direction matters.
One connection has one four-tuple, and each direction reads it the other way round:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
The client port is often temporary. The server port is the stable listening port.
The server first owns a listening socket on port 15000. Accepting a client creates a separate connected socket while the listener remains available for other clients. The client normally receives an ephemeral local port selected by Windows.
Section: Follow the stream.
Wireshark’s “Follow T C P Stream” view reassembles T C P bytes for easier inspection.
Alternative: Picture T C P as one long ribbon: reads cut pieces from it, while your parser identifies complete messages.
Remember: this is still a stream, not necessarily a list of messages. Look for:
fixed-size headers;
length fields;
magic bytes;
repeated separators;
readable text;
compressed-looking regions;
request/response pairs.
“Follow T C P Stream” performs reassembly for inspection. Your client still has to handle partial reads: read() may return fewer bytes than requested even when more bytes will arrive later. read_exact is appropriate only after a validated frame length tells you exactly how many bytes belong to the next piece.
Reassembly also chooses an order from sequence numbers and removes retransmitted overlap. Preserve the original packet capture alongside any exported stream fixture so later questions about direction, timing, or retransmission can still be answered.
Section: Export a tiny fixture.
Save only the bytes for one clearly labeled action. A small binary fixture is excellent for parser tests.
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Do not store secrets, account tokens, or other people’s traffic in fixtures.
Section: Compare two captures.
Repeat the same action with exactly one changed input:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Compare lengths and differing byte ranges. If only one region changes, it may contain the text. If the whole payload changes, compression or encryption may be involved.
Narration: Changing only one input gives differences a clearer meaning than comparing two sessions where everything changed.
Section: Identify the real Wesnoth handshake.
Add this display filter so Wireshark shows client/server data rather than every T C P acknowledgement:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
The first client payload in a Wesnoth 1.14.9 connection is exactly four zero bytes:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Replay only those four bytes from a tiny T C P client. The local server responds with 41 bytes across the observed replies, proving that the zeros begin protocol negotiation. The next client frame identifies version 1.14.9; the following frame logs in with the chosen username.
After the four-byte frame length, both of those later frames begin with gzip magic bytes 1F 8B. For example, a captured version frame begins:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Do the same controlled capture with usernames IEUser and FFFAAAKKKEEE. The second name makes repeated-character compression easier to notice. Put together, the Wesnoth 1.14.9 connection works like this:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Section: Capture facts the parser needs.
A useful frame fixture records:
the start of one frame;
the field that gives its size, or another reliable delimiter;
its direction;
one input and the bytes that changed because of it.