Master Real-Time Messaging: From Polling to WebSocket with Socket.io and Multi-Node Clustering

Related Technologies

Real‑time message push means delivering messages to the browser instantly without requiring a page refresh. Traditional web sites used polling, which forces the browser to repeatedly request the server, wasting bandwidth and causing latency.

Short Polling (Polling)

The client periodically sends requests; only when the server has new data does the next request return useful information, leading to many unnecessary requests.

Comet

To overcome short‑polling drawbacks, a long‑connection “server push” approach called Comet was created. It keeps a persistent connection so the server can push data when it changes. Comet can be implemented as long polling or streaming.

Long Polling The client sends a request and the server holds it until new data is available, then responds, reducing useless HTTP traffic but still limited by at least 2×RTT latency.

Streaming Implemented via an iframe that maintains a long connection; the server pushes data without further client requests, though browsers may show a loading indicator.

WebSocket

HTML5 introduced the WebSocket protocol for full‑duplex communication over a single TCP connection. After an initial handshake, both sides can exchange messages freely. Older browsers (IE10 and below) do not support it.

Handshake request includes headers such as Upgrade , Connection , Sec-WebSocket-Key , Sec-WebSocket-Protocol , and Sec-WebSocket-Version . The server responds with Sec-WebSocket-Accept , which is a SHA‑1 and Base64‑encoded version of the key combined with a GUID.

Socket.io

Socket.io is a JavaScript library built on Node.js that abstracts WebSocket and fallback transports, automatically selecting the best method based on browser capabilities.

Creating a Socket.io server involves listening on a port, handling

message

events, and using

socket.emit

to push messages to connected clients. The client includes the Socket.io client library and uses

socket.emit

and

socket.on

for sending and receiving.

Multi‑Node Cluster Architecture

For single‑machine deployments, Socket.io alone suffices. As traffic grows, a cluster of nodes is needed so clients can connect to any node and still receive messages. This is achieved by using Redis Pub/Sub as a message distribution hub.

Redis

Redis acts as a key‑value store and, in this setup, as a publish/subscribe broker. When a client joins a Socket.io namespace (room), the server subscribes to the corresponding Redis channel. Messages published to that channel are delivered to all servers subscribed, which then forward them to their connected clients.

Nginx

Nginx serves as a reverse proxy, requiring version 1.3+ for WebSocket support. The

ip_hash

directive ensures sticky sessions, keeping a client’s requests routed to the same backend process, avoiding session inconsistencies when fallback polling is used.

Architecture Diagram

Clients connect via Socket.io namespaces to Nginx, which proxies based on

ip_hash

to a specific Node.js process. The process establishes a WebSocket connection, subscribes to a Redis channel for its room, and receives messages published by any other node handling the same room.

Code Example: Multi‑Room Real‑Time Chat

nginx.conf (requires >1.3)

Define an

upstream

with

ip_hash

so the same IP is consistently routed to the same backend worker.

cluster.js

Implements a multi‑process design that leverages multiple CPU cores; a master process manages worker processes, each listening on its own port.

fork_server.js

Handles spawning of worker processes.

Client

The client loads the Socket.io client library and uses

socket.emit

and

socket.on

to send and receive messages.

Source code: https://github.com/493326889/node-multiple-rooms-chat