WebSocket, Server-Sent Events, HTTP/2 server push, MQTT, AMQP and WebRTC all solve “push the client when something happens”. They have radically different operational profiles — this page is the cheat sheet for picking the right one.
sgcWebSockets ships every mainstream Delphi real-time client and server in the box — so the question stops being “can I do this in Pascal?” and becomes “which protocol fits the job?”
“Real-time communication in Delphi” is an umbrella term — in practice it covers six fundamentally different network primitives, each with different latency, ordering, fan-out, NAT-traversal and infrastructure properties. Choosing wrongly costs months: you ship a polling REST loop, hit scalability ceilings, retrofit a WebSocket layer, then discover MQTT would have been a better fit because your traffic is fundamentally pub/sub. This page is the short, opinionated guide.
Scan the rows; the column with the most green wins.
| Need | WebSocket | SSE | HTTP/2 push | MQTT | AMQP | WebRTC |
|---|---|---|---|---|---|---|
| Bi-directional | Yes | No (server→client only) | No | Yes (pub/sub) | Yes (pub/sub) | Yes (peer) |
| Fan-out broadcast | Server-implemented | Per-client only | Per-stream only | Native (topics) | Native (exchanges) | No (1:1) |
| Browser supported | Yes | Yes | Yes | Via WebSocket | Via WebSocket | Yes |
| Through corporate proxy | Via wss://443 | Yes (looks like HTTP) | Yes | Via WSS | Via WSS | Often (TURN) |
| Guaranteed delivery | App-level | App-level | App-level | QoS 1/2 | Ack’d | SCTP reliable |
| Low-bandwidth devices | Medium | Low | Medium | Excellent | Medium | Medium |
| P2P / NAT traversal | No (server) | No | No | No (broker) | No (broker) | Yes (ICE) |
| End-to-end encrypted | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | TLS hop-by-hop | DTLS-SRTP E2E |
| Server can run in Delphi | Yes | Yes | Yes | Use external broker | Use external broker | Yes (signalling + STUN/TURN) |
Default choice. Bi-directional, low overhead, works in every browser. Pick it for live dashboards, chat, collaborative editing, custom application protocols. Component →
Pick when traffic is server → client only and you want the simplest possible model: a long-lived HTTP response that streams text. Built into every browser without a library. SSE →
Use to pre-emptively send sub-resources (CSS, JS, JSON) alongside the main document — cuts a round-trip. Not a general-purpose “push” channel. HTTP/2 →
Pub/sub for IoT, telemetry, mobile presence, connected vehicles. QoS 1/2, retained messages, last-will, tiny wire overhead. Needs a broker. MQTT →
Enterprise messaging: durable queues, exchanges, routing keys, dead-letter handling, RabbitMQ / Azure Service Bus / IBM MQ. Pick over MQTT when you need rich routing. AMQP →
Direct peer-to-peer with NAT traversal — data channels for collaboration, eventually audio/video. The only option for E2E-encrypted P2P. WebRTC →
The minimum viable Delphi snippet to connect with each protocol — same library, same component pattern.
WS := TsgcWebSocketClient.Create(nil);
WS.URL := 'wss://echo.websocket.events';
WS.OnMessage := DoMessage;
WS.Active := True;
WS.WriteData('hello');SSE := TsgcWSPClient_SSE.Create(nil);
SSE.URL := 'https://stream.example.com/events';
SSE.OnEvent := DoEvent;
SSE.Active := True;MQTT := TsgcWSPClient_MQTT.Create(nil);
MQTT.Client := WSClient;
MQTT.OnMQTTPublish := DoMqttPublish;
WSClient.Active := True;
MQTT.Subscribe('sensors/+/temperature', mtqsAtLeastOnce);AMQP := TsgcWSPClient_AMQP.Create(nil);
AMQP.Client := WSClient;
AMQP.OnAMQPMessage := DoAmqpMessage;
WSClient.Active := True;
AMQP.Consume('orders');H2 := TsgcHTTP2Client.Create(nil);
H2.Host := 'api.example.com';
H2.Port := 443;
H2.TLS := True;
H2.OnResponse := DoResponse;
H2.Connect;
for i := 1 to 10 do H2.Get(Format('/items/%d', [i]));RTC := TsgcWSPClient_WebRTC.Create(nil);
RTC.Client := WSSignal;
RTC.IceServers.Add.URL := 'stun:stun.l.google.com:19302';
RTC.OnDataChannelMessage := DoP2PMessage;
WSSignal.Active := True;
RTC.CreateDataChannel('chat', True, True);
RTC.CreateOffer;If you find yourself calling Get every two seconds and diffing the response, the answer is almost always SSE (server→client only) or WebSocket (bi-directional). The CPU and bandwidth savings are routinely 95 %+.
If your traffic is fundamentally topic-based fan-out (devices publishing telemetry, dashboards subscribing), running a custom JSON-over-WebSocket protocol re-implements MQTT badly. Use the broker.
HTTP/2 push promise is a sub-resource optimisation, not a general push channel. For long-lived server-to-client streams you still want SSE, WebSocket or MQTT.
The flagship transport.
IoT and telemetry pub/sub.
Multiplexed HTTP and push.
Peer-to-peer data channels.
Simple server→client streaming.
Enterprise messaging via RabbitMQ, Service Bus, IBM MQ.
Practical SSE example.
How to put nginx / Envoy / ALB in front of WebSocket and HTTP/2.