Building a Simple Chat Application

During the last over of a close IPL match on a streaming app, the live-chat panel next to the video can carry several thousand comments a minute. A fan taps out "SIXXX 🔥" and, within a second, that same line has to show up on every other fan's screen who is watching the same match — not just the one server that received it. That single requirement — one client's message, fanned out to every other connected client, in real time, over an unreliable mobile network — is the entire engineering problem behind a chat application. Everything else (usernames, emojis, read receipts) is decoration on top of this core mechanism: a server that keeps many clients simultaneously connected and relays what one says to the rest. This chapter builds that mechanism from first principles, in about eighty lines of Python, and — more importantly — shows exactly where the naive version breaks and why.

Why a Chat App Cannot Be "Just an API Call"

A request like fetching a weather forecast fits the request-response pattern you have already used with HTTP: the client opens a connection, sends one request, gets one response, and the connection can close. Chat does not fit that pattern for two reasons. First, a client needs to receive messages it did not ask for, at a time it cannot predict — someone else might type at any moment. Second, many clients need to reach the same server session simultaneously so that messages can be relayed between them. Both requirements point to a persistent, bidirectional connection between each client and the server, kept open for the lifetime of the chat session. That is exactly what a TCP socket gives you, and it is why chat applications, unlike most web pages, are built directly on top of the socket layer rather than on one-shot HTTP requests.

Sockets: The Addressable Endpoint

A socket is the operating system's abstraction for one endpoint of a network connection. Creating one with Python's socket module and the arguments AF_INET (use IPv4 addresses) and SOCK_STREAM (use TCP, a reliable byte stream) gives you an object with bind(), listen(), accept(), connect(), send()/sendall(), and recv(). A live TCP connection is uniquely identified by a 4-tuple: (source IP, source port, destination IP, destination port). The server binds to one fixed, known port (in the code below, 5050 on 127.0.0.1) and listens for arrivals; each connecting client gets an OS-assigned ephemeral port on its own side, so the server can distinguish thousands of simultaneous clients even though they all target the same destination port.

Before any bytes of chat data move, TCP performs its three-way handshake: the client sends a SYN segment, the server replies SYN-ACK, and the client confirms with ACK. Only after this completes does accept() on the server return a usable connected socket. You do not write handshake code yourself — the OS's TCP/IP stack does it — but it explains why connect() can fail with a connection-refused error the instant no process is listening on the target port, and why the connection, once established, guarantees in-order, lossless delivery of whatever bytes you write to it.

From One Client to Many: The Broadcast Architecture

A server that only ever talks to one client is a monologue app, not a chat app. The standard way to serve many clients at once with blocking sockets is thread-per-client: an accept loop runs forever, and each time accept() returns a new connected socket, the server spins up a dedicated thread whose only job is to sit in a loop calling recv() on that one client. Every thread shares one list of all currently connected sockets; whenever any thread receives a complete message, it calls a shared broadcast() function that walks that list and forwards the message to every other client. The diagram below shows this exact shape for three connected clients.

The Core Misconception: "One recv() Equals One Message"

Students who have used sendall() and recv() for the first time almost always assume that if the client calls sendall(b"HI\n") and then sendall(b"BYE\n"), the server will get exactly two recv() calls back, one per message. This is false, and it is the single most important fact about TCP sockets. TCP delivers an unstructured stream of bytes, not a sequence of framed messages. The two ends of the connection, and every router in between, are free to buffer, coalesce, or split the bytes you write however is convenient for them, as long as the final byte order is preserved. Two sendall() calls made in quick succession can easily arrive as a single recv() returning both messages concatenated together; conversely, one large sendall() can arrive split across two or more recv() calls if it exceeds a buffer size somewhere along the path. TCP guarantees order and completeness of the byte stream — it makes no promise whatsoever about where one send ends and the next recv begins.

The practical consequence: if the server naively does data = client_socket.recv(1024); print(data.decode()) and treats whatever comes back as "the message," it can receive b"HI\nBYE\n" in a single call and treat it as one chat bubble, or it can receive a message chopped in half across two calls and try to process an incomplete fragment. The fix is application-level framing: the sender and receiver agree on a way to mark where each message ends, and the receiver accumulates bytes into a buffer until it has seen a complete message before acting on it. The code below uses the simplest scheme, a b"\n" delimiter (workable because chat text itself will not contain a raw newline once you strip user input); production protocols more often use a fixed-width length prefix so the framing does not depend on the payload's content at all.

Worked Example: Tracing the Byte Stream Through the Buffer

Suppose Client A's two sendall() calls happen to arrive at the server as a single recv() — a real possibility, not a contrived one. Trace exactly what handle_client does with it, byte by byte.

1. buffer = b"" — the thread starts with an empty buffer.
2. chunk = client_socket.recv(1024) returns b"HI\nBYE\n" — 7 bytes: H, I, \n, B, Y, E, \n.
3. buffer += chunk → buffer = b"HI\nBYE\n".
4. Loop condition: is b"\n" in buffer? Yes.
5. buffer.split(b"\n", 1) splits at the first newline (index 2), giving line = b"HI" and the remainder buffer = b"BYE\n".
6. broadcast(b"HI" + b"\n", client_socket) is called — Client A's first message goes out to every other connected client.
7. Loop condition again: is b"\n" in the new buffer = b"BYE\n"? Yes.
8. buffer.split(b"\n", 1) gives line = b"BYE", remainder buffer = b"".
9. broadcast(b"BYE" + b"\n", client_socket) is called — the second message goes out.
10. Loop condition: is b"\n" in buffer = b""? No — exit the inner while, go back to recv() and wait for more bytes.

Both messages were correctly recovered and broadcast separately, even though they arrived in one physical recv() call, because the code buffers first and only acts once it has found a complete, delimited message. A version without the buffer-and-split logic — one that assumed recv() returns exactly one message — would have broadcast the single garbled string "HI\nBYE\n" as though it were one chat line.

Full Working Code

The server keeps one shared list of connected sockets, protected by a lock, and one thread per client:

import socket
import threading

HOST = "127.0.0.1"
PORT = 5050

clients = []          # list of connected client sockets
clients_lock = threading.Lock()

def broadcast(message, sender_socket):
    """Send message to every connected client except the sender."""
    with clients_lock:
        for client in clients:
            if client is not sender_socket:
                try:
                    client.sendall(message)
                except OSError:
                    pass  # client dropped; cleanup happens in handle_client

def handle_client(client_socket, address):
    print(f"[CONNECTED] {address}")
    buffer = b""
    with clients_lock:
        clients.append(client_socket)
    try:
        while True:
            chunk = client_socket.recv(1024)
            if not chunk:
                break                      # peer closed the connection
            buffer += chunk
            while b"\n" in buffer:
                line, buffer = buffer.split(b"\n", 1)
                broadcast(line + b"\n", client_socket)
    finally:
        with clients_lock:
            clients.remove(client_socket)
        client_socket.close()
        print(f"[DISCONNECTED] {address}")

def start_server():
    server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    server_socket.bind((HOST, PORT))
    server_socket.listen()
    print(f"[LISTENING] Server is listening on {HOST}:{PORT}")
    while True:
        client_socket, address = server_socket.accept()
        thread = threading.Thread(target=handle_client, args=(client_socket, address), daemon=True)
        thread.start()

if __name__ == "__main__":
    start_server()

The client mirrors the same framing logic on the receiving side, and runs its own recv() loop on a background thread so it can display incoming messages while the main thread is free to block on input() for the next line to send:

import socket
import threading

HOST = "127.0.0.1"
PORT = 5050

def receive_messages(sock):
    buffer = b""
    while True:
        chunk = sock.recv(1024)
        if not chunk:
            print("[SERVER CLOSED CONNECTION]")
            break
        buffer += chunk
        while b"\n" in buffer:
            line, buffer = buffer.split(b"\n", 1)
            print(line.decode("utf-8"))

def start_client():
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((HOST, PORT))
    threading.Thread(target=receive_messages, args=(sock,), daemon=True).start()
    while True:
        text = input()
        sock.sendall((text + "\n").encode("utf-8"))

if __name__ == "__main__":
    start_client()

Two design details are easy to miss and worth naming explicitly. First, clients_lock exists because clients is read and mutated from many threads at once: without the lock, one thread appending a new client while another is mid-iteration inside broadcast()'s for loop is a race condition — Python lists (unlike dicts or sets) raise no error when mutated mid-iteration, so the actual symptom is silent: a client can be skipped by broadcast()'s for loop, or a thread can call sendall() on a socket another thread has already closed (usually swallowed by the except OSError, but only by luck of timing). Second, clients.remove(client_socket) is an O(n) operation — Python's list.remove scans linearly to find the matching element — so cleanup on disconnect costs time proportional to how many clients are currently connected. A set() would make removal O(1) on average at the cost of losing the clients' join order, a genuine data-structure tradeoff a real chat server has to choose between.

Worked Example: The Cost of Broadcasting

Broadcasting is not free, and its cost is worth deriving precisely rather than waving at. Take a server with n = 50 connected clients, each sending an average of 4 messages per minute:

Each call to broadcast() is O(n): it walks the entire clients list once per incoming message, regardless of how many of those clients actually want the message. This is the standard complexity of a naive fan-out — cheap to reason about, but it means the total work the server does is not just proportional to the number of messages typed, but to messages × recipients.

Why TCP, Not UDP

Sockets can also be created with SOCK_DGRAM for UDP, which is faster per packet but drops the guarantees TCP provides: no ordering guarantee (packet 2 can arrive before packet 1), no delivery guarantee (packets can simply vanish), and no built-in notion of a "connection" to detect when a peer has gone away. A chat message that arrives out of order or not at all is a broken conversation, not a minor glitch — so chat applications default to TCP, accepting its higher per-packet overhead in exchange for the ordering and reliability the application would otherwise have to reimplement by hand. (Real-time voice or video calls make the opposite tradeoff, favoring UDP because a dropped video frame is preferable to a frozen call waiting for retransmission — but text chat is squarely in TCP's use case.)

Active Recall

Attempt each question before reading its answer.

1. Why is client_socket.recv(1024) not guaranteed to return exactly one chat message, even though the client called sendall() once per message?
2. Walk through, step by step, what happens to the buffer in handle_client when a thread receives b"HI\nBYE\n" in a single recv() call.
3. With 50 clients connected, how many sendall() calls does one call to broadcast() make, and why not 50?
4. What specific bug can occur if clients_lock is removed from handle_client and broadcast, while two clients connect or disconnect at nearly the same instant?
5. Worked Example 2 used n = 50 clients at 4 msg/min each, giving ≈163.3 broadcast sendall() calls/second. Recompute that figure, the thread count, and the recipients-per-message figure if the server scales to n = 120 clients at the same per-client rate. Does the total workload scale linearly with n?
6. Why does the chat server use socket.SOCK_STREAM (TCP) instead of SOCK_DGRAM (UDP)?

Answers

1. TCP delivers an unstructured byte stream, not framed messages. The OS on either side may buffer, coalesce, or split writes independently of how many times the application called send. Two back-to-back sendall() calls can arrive merged in one recv(), and one large sendall() can arrive split across several. The application must impose its own framing — here, a b"\n" delimiter combined with a buffer — to recover message boundaries.

2. buffer starts empty; recv() adds b"HI\nBYE\n" to it. The inner while b"\n" in buffer loop first splits at the earliest newline, producing line = b"HI" and leaving buffer = b"BYE\n"; that line is broadcast. The loop condition is checked again, a newline is still present, so it splits once more into line = b"BYE" and buffer = b""; that line is broadcast too. With no newline left, the loop exits and the thread returns to recv(). Both messages are recovered correctly despite arriving in a single physical read.

3. 49, not 50 — broadcast()'s if client is not sender_socket check skips the client that sent the message, since there is no reason to echo a message back to its own author.

4. Without the lock, threads can mutate the shared clients list concurrently: one thread's append() or remove() interleaving with another thread's for client in clients iteration inside broadcast() is a race condition. Concretely, Python lists (unlike dicts or sets) raise no error when mutated mid-iteration, so the symptom is silent: a client can be skipped by broadcast()'s for loop if it is added or removed while the loop is mid-iteration, or a thread can call sendall() on a socket another thread has already closed, usually caught by the except OSError but only by luck of timing. The lock forces every read-then-modify sequence on clients to run one thread at a time, eliminating that interleaving.

5. At n = 120: total incoming rate = 120 × (4/60) = 8 msg/s; recipients per broadcast = 119; sendall() calls/second = 8 × 119 = 952; live threads = 120 + 1 = 121.

The client count grew by a factor of 2.4 (120/50), but the sendall() rate grew by a factor of 5.83 (952/163.3) — not 2.4. The naive mistake is to rescale only the recipient count (n − 1) and assume the total workload scales the same way; it misses that the incoming message rate is itself proportional to n, since every one of the n clients is independently generating traffic. With both the number of senders and the fan-out size tied to n, total broadcast work scales roughly as n × (n − 1) ≈ O(n²), not O(n) — doubling the user base roughly quadruples the server's broadcast workload, which is why naive thread-per-client broadcast servers degrade sharply well before they run out of threads.

6. Chat requires reliable, in-order delivery: TCP guarantees the bytes you send arrive intact and in the order written, retransmitting lost segments transparently, and it gives a clear signal (recv() returning b"", or a socket exception) when the connection breaks. UDP offers none of this — packets can be dropped, duplicated, or reordered — so a chat client built on UDP would have to reimplement sequencing and retransmission itself just to guarantee messages show up once, in the order they were typed. TCP already does this at the transport layer, which is exactly what the server's framing logic assumes when it trusts that bytes across multiple sendall() calls arrive in the order they were sent.

Think About It

Think about this: How would you explain building a simple chat application to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where building a simple chat application is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting building a simple chat application to at least 3 other topics you have studied.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind building a simple chat application, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.