Comparison and Choice: Where Does the Change Come From, and What Does It Cost?

Objectives

By the end of the lesson, you can compare the communication methods along the seven aspects, know where Socket.IO fits, and justify a choice for a concrete need.

Why is it needed?

The course led from the request–response styles to the persistent, two-way channel. The task is always the same: which method fits the given need, and what does it give in return. The best-known tool is not necessarily the simplest suitable solution.

The comparison

Method	Direction	Initiator	Connection	Latency	Load	Fault tolerance	When it fits	When it does not
Request–response (REST, RPC, GraphQL; ch. 7)	Request + response	Client	Per request	One round trip	Proportional to requests	An idempotent request can be repeated	Operations, resource reads	Changes from the server side
Message queue / pub-sub / log (ch. 8)	Producer → consumer(s)	Producer	Through the broker	Depends on queue length	Buffer, backpressure	Acknowledgement, retry, DLQ	Asynchronous work between services	An immediate answer is needed
Webhook (8.5)	Source → receiver	Source	One request per event	Quick after the event	Per event	Duplication, idempotent receiver	Server-to-server notification	Updating a browser
Polling (9.1)	Client asks	Client	Per request	Half to one period	N/T, constant	Simple	Rare changes, simplicity	Dense changes, many clients
Long polling (9.2)	Server answers with delay	Client	Long-open request	Low, but the re-request gap	Fewer empty requests	A cursor is needed	Lower latency, no persistent channel	Frequent messages
SSE (9.3)	Server → client	Client opens, server sends	Persistent HTTP response	Low	Open connection	Auto-reconnect + Last-Event-ID	One-way live status	Dense two-way traffic
WebRTC DataChannel (9.4)	Peer ↔ peer	Either peer	Persistent, direct	Low	Between peers	Configurable reliability	Peer communication, fast-expiring data	Authentic central state
WebSocket (ch. 10)	Two-way	Connection: client; message: either	Persistent	Low	Connection × rate	Left to the application	Frequent two-way messages	Rare one-way notification

The table shows architectural differences; the exact capability depends on the environment and does not replace examination of browsers and infrastructure.

Where does Socket.IO fit?

Socket.IO is a higher-level communication solution with its own protocol and client and server libraries. According to the documentation it consists of two layers: the low-level Engine.IO manages the connection (with a WebSocket, WebTransport or, in the worst case, HTTP long-polling transport; by default the client starts with a long-polling connection and then tries to upgrade), and the high-level Socket.IO adds further capabilities: automatic reconnection, packet buffering, acknowledgements, and broadcasting to all clients or a subset. Engine.IO also contains a heartbeat mechanism.

Important: Socket.IO is not the same as the native WebSocket. Socket.IO uses its own protocol over WebSocket (or another transport), so a plain WebSocket client cannot talk to it automatically. The guarantees of Socket.IO: it guarantees ordering independently of the transport; by default it provides at-most-once delivery; a disconnected client may buffer events until reconnection, whereas the server does not; from client to server at-least-once delivery can be achieved with acknowledgement and retries; from server to client durability must be solved by the application, with unique event identifiers and a stored offset.

Decision questions

1. Who initiates? Only the client, only the server, or both?
2. How often does the data change, and how much delay is acceptable? A few seconds: polling; immediate one-way: SSE; immediate two-way: WebSocket.
3. Is the latest state enough, or are all intermediate events needed? The latter needs a log, replay or a durable queue.
4. Is the connection made with a central server or with a peer?
5. Is it a server-to-server notification? Webhook or message queue.
6. What is the reliability need? At most once, at least once; who copes with duplication?
7. What does the infrastructure tolerate? Proxy, idle timeout, number of connections.

Examples (not recipes): polling may be enough for the status of a long task; SSE is natural for a notification feed; for chat WebSocket or a higher-level library; for fast-expiring positions a partly reliable peer channel; for handing events between services a message queue or a webhook.

Fallback transport and the same meaning

If a system falls back from WebSocket to long polling, the application contract must still mean the same result; there must not be different authorisation or repetition protection merely because of the difference of transport. Connection state and performance limits, however, must be checked on both paths.

Common misconceptions

Statement	Clarification
"Real-time updates always need WebSocket."	Polling or SSE may be adequate.
"Socket.IO = WebSocket."	Its own protocol and library, with several transports.
"A higher-level library gives exactly-once delivery."	The default is at-most-once; the rest must be configured or built.
"One method fits everything."	Every method is a trade-off; several can coexist.

In short

• Methods are compared by direction, initiator, persistence, latency, load, fault tolerance and applicability.
• The choice is decided by the initiator, the frequency, the reliability and the infrastructure.
• Socket.IO is its own protocol and library, not native WebSocket.
• WebSocket is justified when both parties initiate frequently; otherwise a simpler method is also enough.

Review questions

1. Which method would you choose for a slowly changing state, and which for shared editing?
2. How does Socket.IO differ from native WebSocket?
3. What should be done if the transport falls back to long polling?

Learning resources

• How it works (Socket.IO) — Engine.IO, transports, features.
• Delivery guarantees (Socket.IO) — ordering, at-most-once delivery, acknowledgements.
• WebSocket API (MDN) — the relation of WebSocket and WebTransport.