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

• (a) TCP. SOCK_STREAM = a reliable, ordered byte stream. Picture a continuous pipe of bytes.
• (b) UDP. SOCK_DGRAM = independent datagrams (postcards). Each sendto is one self-contained packet.
• (c) UDP. recvfrom returns (data, addr) — you learn who sent it because there is no fixed connection. TCP uses plain recv (the peer is already known).
• (d) TCP. listen makes a socket passive (willing to queue incoming calls). UDP has no calls to queue, so it never uses listen.

• '127.0.0.1' = the IP address (here the loopback address = "this same machine").
• 9000 = the port = which door on that machine this program answers. Together they form the local address the socket claims. See Ports and IP addressing. A client must target exactly this (IP, port) to reach the server.

• conn = a brand-new socket dedicated to this one client.
• addr = the client's (IP, port). The original listening socket s must stay free to keep accepting other clients. So the OS hands you a separate socket for the actual conversation. This split is exactly why one server can serve many clients: one listener, many conns.

• A = socket.SOCK_STREAM (TCP).
• B = listen — go passive. The 1 is the backlog (the waiting-bench size defined at the top of the page): here at most 1 completed-but-unaccepted connection may wait.
• C = accept — blocks until a client dials, returns the per-client socket.
• D = recv — read up to 512 bytes from the stream. Order matters: you cannot accept before listen, and you cannot listen/accept before bind (you need an address first).

Sockets carry bytes, not str. Fix the client:

c.send("hello".encode())   # or  c.send(b"hello")

On the server, decode back to text:

text = conn.recv(1024).decode()   # bytes -> str

"hello".encode() produces 5 bytes (UTF-8); .decode() reverses it. This is the single most common beginner error.

import socket
c = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
c.sendto(b"ping", ('127.0.0.1', 6000))   # address travels WITH the packet
reply, addr = c.recvfrom(1024)
print(reply.decode())
c.close()

No connect, no bind on the client — the OS auto-picks an ephemeral source port, and the destination lives in the sendto call itself. Contrast with UDP vs TCP tradeoffs.

TCP is a byte stream — it does not preserve message boundaries. A single recv(1024) may return:

• b"ABC" (all three coalesced — most common on localhost), or
• b"A", then later b"BC", or
• b"AB", then b"C", or
• b"A", b"B", b"C" across three recv calls. What you will never see is bytes out of order or missing (TCP guarantees order + delivery). The bytes always arrive as A B C in sequence — only the chunking varies. This is why you need Message framing / length-prefix protocol.

UDP preserves message boundaries but guarantees nothing about delivery or order:

• Each recvfrom returns exactly one whole datagram: you get b"A", b"B", b"C" individually — never b"ABC" from one call.
• But any of them may be lost, duplicated, or reordered (e.g. you might read C, A, B, or only A, C). Boundary-preserving but unreliable — the exact opposite trade of TCP. See UDP vs TCP tradeoffs.

In TCP, recv returning b'' is not "empty data" — it is EOF: the peer has closed the connection (orderly shutdown). Looping without checking spins forever on zero-length reads. Fix: treat b'' as end-of-stream and break:

while True:
    data = conn.recv(1024)
    if not data:          # b'' -> peer closed
        break
    handle(data)
conn.close()

Scheme: every message = [4-byte length N][N bytes of payload]. The receiver reads 4 bytes first, learns N, then reads exactly N more bytes (looping, since each recv may return less). This matches the two-step trace in the figure above. Sender:

import struct
def send_msg(conn, payload: bytes):
    header = struct.pack('>I', len(payload))  # '>I' = big-endian unsigned 4-byte int
    conn.sendall(header + payload)

Receiver — a robust "read exactly n bytes" helper first:

def recv_exact(conn, n):
    buf = b''
    while len(buf) < n:
        chunk = conn.recv(n - len(buf))
        if not chunk:                 # b'' -> peer closed early
            raise ConnectionError("peer closed mid-message")
        buf += chunk
    return buf
 
def recv_msg(conn):
    header = recv_exact(conn, 4)
    (length,) = struct.unpack('>I', header)  # 4 bytes -> int
    return recv_exact(conn, length)

Why it works: the length tells us exactly how many payload bytes belong to this message, so coalescing/splitting no longer confuses us — we always stop at the right byte. See Message framing / length-prefix protocol.

Numeric check (in decimal and hex — hex was introduced at the top of the page): the header for a 300-byte payload is struct.pack('>I', 300), which is the 4 bytes shown in the figure. In plain decimal, $300=1\times 256+44$: so the third byte is 1 and the fourth byte is 44. Writing those four byte-values in hexadecimal (two hex digits per byte) gives 00 00 01 2C, because 44 in base 16 is 0x2C ($2\times 16+12=44$). Verified below.

After a TCP connection closes, the OS keeps the local (IP, port) in the TIME_WAIT state for ~1–2 minutes to catch stray late packets from the old connection. A fresh bind on that exact port is refused during this window. Fix — set SO_REUSEADDR before bind:

s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 9000))

This tells the OS "it's fine to reuse an address stuck in TIME_WAIT." Details: TIME_WAIT and SO_REUSEADDR.

c.connect(('example.com', 80))

connect internally resolves the name via DNS (or you can do it explicitly with socket.gethostbyname('example.com'), which returns an IPv4 string). DNS is the phone book mapping human names → IP addresses; see DNS. Port 80 is the well-known port for HTTP.

Serve many sequentially: wrap accept + handle in a loop, and do not close the listening socket:

while True:
    conn, addr = s.accept()   # blocks for each new client
    data = conn.recv(1024)
    conn.sendall(b"echo: " + data)
    conn.close()              # close the per-client socket, keep s open

Serve many concurrently without threads: use an event loop that watches many sockets and wakes only on the ready ones — select or asyncio. One process, many live conns, no blocking accept monopolizing the show. See select / asyncio for concurrent servers. Key insight: the listening socket s and each connection socket conn are different objects — that separation is what lets one server multiplex clients.

Yes — a zero-length UDP datagram is a real, valid packet. The server's recvfrom(1024) unblocks and returns (b'', addr): empty payload, but a real sender address. Contrast with TCP, where recv returning b'' means the peer closed the connection. In UDP b'' just means "an empty postcard arrived" — there is no connection to close. Same-looking value, opposite meaning: this is a favourite exam trap.

TCP sets up a connection with the three-way handshake: SYN → SYN-ACK → ACK = 3 messages before any data. This is what makes TCP a "phone call" (dial, ring, pick up). See TCP three-way handshake. UDP is connectionless: no handshake, so a client's very first sendto already carries data — 0 setup round-trips. That saved latency is exactly why DNS, gaming, and voice use UDP (UDP vs TCP tradeoffs).

Recall the backlog definition from the top of the page: it is the size of the short "waiting bench" of connections that have finished connecting but have not yet been accepted. So 5 bounds that queue — at most 5 completed-but-unaccepted connections may wait. What happens to the 6th? If a 6th client completes its connection while the queue is already full and the server has not drained it with accept, the OS may refuse or drop that connection. The client then sees a connection error (or its TCP stack silently retries). Crucial: the backlog does not limit total or concurrent clients — it is only a buffer for bursts. As long as your server keeps calling accept, the bench keeps emptying and new clients keep succeeding. To actually serve many clients you fix your accept-loop / concurrency model (Exercise 5.1), not this number.

Name the calls (L1) → write them in order with bytes not str (L2) → predict that TCP streams / UDP datagrams behave differently (L3) → build framing + port reuse + DNS (L4) → reason about concurrency, EOF, handshakes, backlog (L5).