Stateless TCP - Notebook Transcript (OCR)
This transcript preserves contemporaneous notes without modernization or reinterpretation.
Any uncertain or illegible text would be marked in brackets if present.
Original scan (PDF)
Page 1
Stateless TCP
Goal: build a TCP server that maintains no per-connection state.
No connection tables
No per-client memory
No open-file state
Server behavior is determined entirely by:
- source/destination ports
- sequence numbers
- acknowledgement numbers
The server does not remember previous packets. Each packet is handled independently.
Incoming packet → compute response → discard contextPage 2
Basic idea
Treat TCP as a request protocol, not a stream.
- Client requests data implicitly via ACK + sequence number
- Server responds with data derived from those numbers
Proposed mapping:
- Port number → file or object identifier
- Sequence number → offset into file
Example:
Port 80 → main index file
Port 81 → secondary file
Port N → file N
Sequence number / block size = block index
Block size is fixed (e.g. 256 or 512 bytes).
Server logic:
offset = seq_number * BLOCK_SIZE
read BLOCK_SIZE bytes from file
send as TCP data
Server does not track where the client “is” in the file.Page 3
Data flow
1. Client sends initial packet with sequence number
2. Server sends one or more data segments
3. Client ACKs received data
4. ACK implies request for next block(s)
The ACK is the request.
Server may choose to send:
- one block per ACK, or
- multiple blocks per ACK
This trades bandwidth efficiency vs. simplicity.
No sliding window is maintained.Page 4
Navigation between files
Client selects a file by connecting to a different port.
Example:
- Port 80 → main page
- Port 81 → linked document
- Port 82 → another document
A “link” is effectively:
- new TCP connection
- different destination port
- sequence number reset
This replaces URLs with port selection.
[Note: crude, but simple]Page 5
Limitations
This model works best for:
- static files
- read-only content
- pre-sized objects
Problems:
- No congestion control
- No fairness between clients
- No server-side retransmission tracking
Packet loss must be handled implicitly by the client re-requesting blocks via sequence numbers.
Server does not detect loss explicitly.Page 6
Dynamic data
Dynamic or generated content breaks the stateless assumption.
Possible workarounds:
- pre-generate dynamic content into static snapshots
- treat generated output as immutable once requested
True per-client dynamic state cannot be supported without storing state.
Conclusion:
Stateless TCP is viable only for a limited class of problems.
Primary benefit:
- extreme simplicity
- resistance to state-exhaustion attacks
Tradeoff:
- reduced flexibility
- reduced throughput