Foundations — Socket programming — TCP server - client, UDP server - client in Python

Before you can read a single line of socket code, a handful of words must stop being magic. We build each one from nothing, anchor it to a picture, and only then let it appear in a call. Nothing below assumes you have seen networking before.

1. Byte — the only thing that ever travels

The picture: imagine a row of 8 tiny lightbulbs. Each is on (1) or off (0). One such row = one byte. A message is just a long line of these rows.

Why the topic needs it: the network card does not understand the idea of "a Python string" or "an integer" — it only ever moves bytes. So every socket call sends and receives bytes objects, written in Python with a b in front: b"hello". That single b is the source of the parent note's first big mistake ("I'll just send a string").

2. Process — the thing that owns your code while it runs

The picture: two sealed rooms. Inside each is one running program. No window between them. If room A wants to hand something to room B, it must slide it under the door — through some channel the outside world (the OS) controls.

Why the topic needs it: this isolation is the entire reason sockets exist. If the two programs shared memory, they'd just read the same variable. Because they don't, they need a channel — and the socket is that channel.

3. The Operating System (OS) and the network card

The picture: the NIC is a mail slot in the wall of the building; the OS is the building's front desk that alone may use the slot. Your process must ask the front desk to send mail for it.

Why the topic needs it: you never talk to the wire directly. You ask the OS. The socket API (a set of function calls like send, recv) is exactly the language you use to make those requests.

4. IP address — which machine

The picture: a street address on an envelope. It gets your letter to the right building.

The special one, 127.0.0.1: this is localhost — a loopback address meaning "this very same machine". Bytes sent here never leave the computer; they turn around inside the OS. The parent note uses it so the server and client can run on one laptop.

Why the topic needs it: a socket must know which computer to reach. Without an IP, the OS has no idea where to steer the bytes. See Ports and IP addressing for the full breakdown.

5. Port — which program on that machine

The picture: below. The IP is the building; ports are numbered mailboxes on the wall. Two programs on one machine listen on two different mailbox numbers so replies don't get mixed up.

Why the parent uses 9000 and 9001: the TCP demo listens on port 9000, the UDP demo on 9001 — different mailboxes so the two servers never collide. Ports below 1024 are reserved for system services; that's why the examples pick high numbers.

6. Socket — the doorway itself (the tuple)

The picture: a single labelled doorway with a sign on it listing all five facts. Once all five are filled in, the OS knows exactly which stream of bytes belongs to this doorway and nobody else's.

Why the topic needs it: every socket call in the parent note is filling in one or more of these five slots. bind fills the local pair. connect fills the remote pair. Understanding this makes the call list stop being arbitrary.

7. Client vs Server — who waits, who walks over

The picture: a shopkeeper standing behind a fixed counter (server) versus a customer who walks in (client). The customer needs to know where the shop is; the shop just waits.

Why only the server binds: the client doesn't need a fixed address — nobody has to find it, it does the finding. So when a client connects, the OS quietly assigns it a throwaway ephemeral port. This is the reason the parent note says "the client normally doesn't bind".

8. TCP vs UDP — the two personalities of the doorway

The picture: below. TCP is water poured into a pipe — it comes out as one continuous flow with no marks showing where each pour began. UDP is separate sealed postcards — each keeps its edges, but some fall out of the mailbag.

Why the reliability costs something: to guarantee order and delivery, TCP first performs a setup ritual (the TCP three-way handshake) and tracks/re-sends lost pieces. UDP skips all that, which is why it is faster but lossy.

9. "Blocking" — why accept and recv pause

The picture: the shopkeeper freezes, staring at the door, doing nothing else until a customer walks in. accept() blocks until a client dials; recv() blocks until bytes arrive.

Why the topic needs it: the parent note's comment # BLOCKS until a client dials only makes sense once you know a call can pause. Later, escaping this freeze is exactly what select / asyncio for concurrent servers is about.

10. Two leftover terms the parent leans on

Equipment checklist

Test yourself — cover the right side and answer before revealing.