terminalChat

What it is

Networking with the abstractions removed

In a high-level language, "send a message" is one line. In C, you confront everything underneath it: open a socket, bind it, listen, accept connections, read bytes into a buffer, handle a client that disconnects mid-sentence, and broadcast to everyone else — all while managing memory yourself. terminalChat is a server that juggles many simultaneous clients and the small client that talks to it.

The crux is handling many connections at once without threads spiralling out of control. A single loop watching all sockets with select() — ready to read from whichever client speaks next — is the classic, elegant answer, and building it teaches the foundation every network server is built on.

The stack

From keystrokes to everyone's screen

Close to the metal — the OS primitives, used directly.

Architecture

How a message reaches everyone

The server runs one loop that never blocks on a single client:

1. Listen

   The server opens a socket and waits for connections.

2. Accept

   Each new client is added to the set of watched sockets.

3. Poll

   select() reports which sockets have data ready to read.

4. Read

   The server reads the message from whichever client sent it.

5. Broadcast

   It relays that message to every other connected client.

The real thing

Two clients, one broadcast

This is the actual end-to-end smoke test: it starts the C server, connects two separate client processes, and one client (bob) receives the message the other (alice) sends. The transcript below is bob's real terminal output — captured, not mocked.

* welcome to TerminalChat — type your nickname:
* you are now known as bob
* alice joined the chat
alice: hello from alice
* alice left the chat

The program is real C. Build it with make (or one gcc line), run the server, and point clients at it:

# build everything (server, client, framing test)
$ make

# terminal 1 — start the server
$ ./bin/server 5050

# terminal 2 — join the chat
$ ./bin/client 127.0.0.1 5050

It's portable: the same source builds on Windows (Winsock2, linked with -lws2_32) and on Linux/macOS (POSIX sockets), guarded by #ifdef _WIN32. A unit test on the message-framing functions reports all 23 assertions passed.

Reflection

What building it taught me

• Sockets are just file descriptors. The OS treats a network connection like a file you read and write — once that clicks, networking demystifies.
• Concurrency without threads. A single select() loop handles many clients elegantly — the model behind the fastest servers.
• C makes you own everything. Every buffer, every byte, every freed resource is yours — unforgiving, and deeply educational.
• Partial reads are real. Data arrives in chunks, not tidy messages; framing and buffering are where naive code breaks.
• Disconnects are the hard case. A robust server is mostly about gracefully handling clients that vanish.