Build a Mini Multiplexed Chat
Final project: one transport carries chat, presence, and file chunks as labeled frames.
One backpack, many labeled pockets
You now know the pattern: one road, labels, fair turns, ports, readiness, event loops, stream IDs, timestamps. Now build the smallest useful thing: many app channels over one transport.
Memorable label: “Pocket protocol.” A tiny protocol is just rules for labels, chunks, order, and rebuilding.
Six-year-old version: Put chat notes, “I am online” cards, and file puzzle pieces into one backpack. Every item has a pocket label.
Protocol shape
Our mini protocol has three fields: channel, sequence, and data. The sender chunks each channel message into frames. The receiver groups frames by channel and sorts by sequence.
Yes, this is the same pattern again. It should feel familiar to Lesson 1. That repetition is the point: HTTP/2 streams, ports, event queues, media tracks, and app channels all reuse “label pieces, share road, sort later.”
A practical version could run over one WebSocket connection. MDN describes WebSocket as a persistent connection for exchanging data between browser and server (MDN WebSockets API). Real systems add flow control, errors, acknowledgements, authentication, compression, and backpressure.
Demo: one transport, three app channels
Send frames across the shared transport. Watch chat, presence, and file rebuild separately.
Mini transport
Rebuilt channels
| Channel | Frames | Message |
|---|---|---|
| chat | 0 | |
| presence | 0 | |
| file | 0 |
Final exercise
node --test tests/mini-mux-chat.test.mjs Open src/mini-mux-chat.mjs. Change chunk size from 4 to 2 in the test call and predict the frame order before running it.
Reveal expected frame order for chunk size 2
chat:0:he
presence:0:on
file:0:AB
chat:1:ll
presence:1:li
file:1:CD
chat:2:o
presence:2:ne
file:2:EF
file:3:GHThe file channel keeps going after chat and presence are finished. Same road, fewer active channels near the end.
Knowledge check
Final payoff
Question: “How do you know when multiplexing is the right tool?”
Model answer: “Use multiplexing when multiple logical conversations need to share one physical or logical resource. Add labels so the receiver can demultiplex, sequence numbers when order matters, scheduling or flow control when channels compete, and buffering when time matters.”
Pro tip: Production protocols are mostly this lesson plus hard parts: failure, fairness, backpressure, security, and observability.
Safety note: The final WebSocket project is a teaching demo. It keeps WebSocket handling deliberately small so multiplexing stays visible. Do not treat it as production networking code.
You can now build: a practical WebSocket app where chat, presence, typing indicators, and file-upload chunks share one socket.
Next: Where to go after this course