Sockets (TCP Client and Server)

diagram the call sequence on both ends of a TCP connection mermaid

  sequenceDiagram
  participant S as Server
  participant C as Client
  S->>S: socket()
  S->>S: bind((host, port))
  S->>S: listen(backlog)
  S->>S: accept()  -- blocks here
  C->>C: socket()
  C->>S: connect((host, port))
  S-->>S: accept() returns a NEW socket for this client
  C->>S: sendall(b"ping")
  S->>S: recv(1024)
  S->>C: sendall(b"pong")
  C->>C: recv(1024)
  C->>S: close()
  S->>S: close() the per-client socket, keep listening

The two sides are not symmetric. A server binds a port, announces it is listening, and then blocks in accept until somebody arrives -- and accept returns a NEW socket for that one conversation, leaving the original still listening. The client only connects. Getting this order wrong is why a server refuses connections or only ever serves one.

TCP has no messages — measured

A client sent two separate calls:

python

c.sendall(b"HELLO")
c.sendall(b"WORLD")

A receiver looping on recv(4) got:

text

[b'HELL', b'O', b'WORL']

Neither sendall arrived as a unit. The first was split across two reads, and the second began in the middle of a read. TCP guarantees the bytes arrive in order and intact; it guarantees nothing about where they are divided.

So recv(n) returning fewer than n bytes is normal, not an error, and two sends can arrive as one read. Any protocol you build on a socket has to say where a message ends, and there are only three ways to do it:

• a length prefix — send four bytes of length, then that many bytes;
• a delimiter — newline-terminated, and you buffer until you see one;
• close the connection to mean “that was everything”.

A loop that assumes one recv equals one message works on localhost with small payloads and fails as soon as there is real latency or a larger body.

What is a socket?

A socket is an endpoint for network communication.

For TCP:

• server listens on (host, port)
• client connects to (host, port)

Simple TCP server

tcp_server.py

import socket
 
HOST = "127.0.0.1"
PORT = 5050
 
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()
    print(f"Listening on {HOST}:{PORT}")
 
    conn, addr = s.accept()
    with conn:
        print("Connected by", addr)
        data = conn.recv(1024)
        print("received:", data.decode())
        conn.sendall(b"Hello client")

Simple TCP client

tcp_client.py

import socket
 
HOST = "127.0.0.1"
PORT = 5050
 
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect((HOST, PORT))
    s.sendall(b"Hello server")
    data = s.recv(1024)
 
print("received:", data.decode())

Tips

• Use 127.0.0.1 for local experiments.
• Choose ports above 1024.
• Add timeouts (s.settimeout(5)) to avoid hanging.

sketch TCP is a byte stream, not a sequence of messages p5.js Pause Restart

A client sent HELLO and WORLD as two separate calls. A receiver looping on recv(4) got HELL, then O, then WORL. Neither send arrived as a unit: the first was split across two reads and the second began in the middle of one. TCP guarantees the bytes arrive in order and intact, and guarantees nothing about where they are divided.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. A client calls `sendall(b'HELLO')` then `sendall(b'WORLD')`. A receiver loops on `recv(4)`. What does it get?

   A `[b'HELLO', b'WORLD']` B `[b'HELL', b'O', b'WORL']` C `[b'HELLOWORLD']` D It raises, because the buffer is too small
   pch.quizShowAnswer

   B — `[b'HELL', b'O', b'WORL']` — Measured. TCP delivers a byte stream — the send boundaries are not preserved, so one send can be split across reads and two sends can merge into one.

2. `recv(1024)` returns 12 bytes. What does that mean?

   A An error occurred B The connection closed C That is normal — it returns what is available D The peer sent exactly 12 bytes
   pch.quizShowAnswer

   C — That is normal — it returns what is available — A short read is ordinary, not exceptional. Only a return of zero bytes means the peer closed the connection.

3. Which of these is NOT a valid way to frame messages over TCP?

   A A length prefix B A delimiter such as a newline C Closing the connection after one message D Assuming each `recv` returns exactly one `sendall`
   pch.quizShowAnswer

   D — Assuming each `recv` returns exactly one `sendall` — That assumption is precisely what the measurement disproves. It appears to work on localhost with small payloads, which is why it survives testing.

4. What does `accept()` return on a listening server socket?

   A The same socket, now connected B A NEW socket for that one client, plus its address C The client's address only D A file descriptor number
   pch.quizShowAnswer

   B — A NEW socket for that one client, plus its address — The listening socket keeps listening; the new socket carries the conversation. Serving only one client is the usual symptom of reusing the listening socket by mistake.

🧪 Try It Yourself

Exercise 1 – HTTP GET with urllib

pch.exerciseTag pch.exerciseTitle

Exercise 2 – Socket Connection

pch.exerciseTag pch.exerciseTitle

Exercise 3 – Resolve a Hostname

pch.exerciseTag pch.exerciseTitle