① Listener
② Thread Pool
③ Request Handler
④ Handle Request
Listener
"receptionist"
Runs forever listens for connections Does nothing → when a connection is made to port 80 she hands over to thread pool. notes - can use port 80 with root/admin priviliges alternative is 8080 needs no root permisions.
click to expand
Listener before Startup does 4 things:
1. Creates socket → file descriptor / communication endpoint. 2. Binds socket to port 8080 → any traffic hitting point 8080 belongs to this socket 3. Listen. Tell the OS to start listening to incoming connections and queue them in a queue. 4. Accept. "The forever loop" - listener just sits and block to "save cpu"
click to expand
Thread Pool
"team of workers sitting idle" waiting on a task
when a client makes connection, gets handed over to thread pool by listener. handle each client fully then goes back to waiting.
click to expand
Key Pieces in Thread Pool
N threads created at startup 1. Queue → Line of pending client connections waiting to be picked up. Listener pushes clients to queue, threads pop out. FIFO 2. Synchronization mechanism
click to expand
Synchronization Mechanism
Mutex + Condition Variable
Two threads "workers" should not grab the same client at the same time "danger zone" Mutex → The lock. Only one worker can look at the queue at a time. Condition variable → instead of threads constantly checking queue for clients, threads sleep and only woken up when sth arrives "condition variable true"
click to expand
Without mutex condition, threads will do the following:
while queue is empty: check queue ← millions of times per second, burning CPU Instead: thread goes to sleep and gets woke up only when listener signals "i just added sth into the queue" while queue is empty: sleep ← consuming zero CPU * listener adds something and signals * thread wakes up instantly → pop from queue → handle client
click to expand
Request Handler
"Brain of each thread worker"
Reads the HTTP request, figures out what the clients wants, finds the file and writes the response back.
click to expand
Thread grabs a client from queue and does 4 things.
1. Read the raw bytes sent by client. 2. Parse the HTTP request. 3. Find and read the requested file. 4. Write the HTTP Response back. Once thread finishes writing back the response, the connection closes and thread goes back to idle watching the queue for the next client.
click to expand
1. Read the raw bytes
The client sent a bunch of raw text over the socket.
The worker reads all of it into a string. It looks something like this in plain text: GET /index.html HTTP/1.1 Host: localhost:8080 User-Agent: Chrome
click to expand
2. Parse HTTP Request
Extracts three things from the raw bytes.
1. The method - is it GET, POST, etc 2. The path - what file is client asking for? eg /index.html or /styles.css etc 3. The HTTP version - to know how to respond properly.
click to expand
3. Find and read File.
The thread takes the path file, maps it to my static folder on disk, opens it and reads the contents into memory.
Two things can happen here: 1. File exists → read it and move to step 4. 2. File doesn't exist → prepare a 404 response instead.
click to expand
4. Write the HTTP response back.
The thread worker sends two things back through the socket.
1. Headers - metadata like status code (200 OK), content type(text, html), content length etc 2. Body - the actual file contents.
click to expand
drag background to pan · drag nodes to move · click any node to expand