Glossary
Long Polling
Long polling is a technique where the client makes an HTTP request and the server holds the connection open until an event occurs (or a timeout expires), then responds and the client immediately makes a new request, simulating server push over plain HTTP.
General definition
Long polling was the dominant technique for achieving real-time updates before WebSocket was standardised. In ordinary (short) polling, a client asks the server “anything new?” on a fixed schedule. Long polling improves on this by holding the connection open at the server until there is actually something to report, then responding immediately. The client receives the response and opens a new connection right away, creating a continuous channel.
- Works over plain HTTP with no protocol upgrade required
- Passes through most firewalls and proxies that block WebSocket
- Higher overhead than WebSocket: each message cycle involves HTTP headers, TCP handshake overhead (without keep-alive) and server-side connection bookkeeping
- Typically introduces more latency than a persistent WebSocket or SSE connection for high-frequency events
- A server timeout (e.g. 30 seconds with no event) sends an empty response to prevent client-side timeout errors
Long polling is still relevant as a fallback mechanism in environments with restrictive network policies, as a simplicity choice when event frequency is low (a few updates per minute rather than per second), or as a compatibility layer for clients that cannot use Server-Sent Events or WebSocket. Many real-time libraries implement all three transports and negotiate down to long polling automatically.
At high concurrency, long polling is expensive because the server must maintain many open connections even when most of them have nothing to send. This is partly why WebSocket and SSE replaced it in most modern architectures, but the technique remains a valid tool in constrained environments.
In the Ethora ecosystem
Ethora’s Chat SDK uses a persistent WebSocket connection (via the XMPP protocol) as the primary real-time transport, which provides lower overhead and lower latency than long polling for the continuous event streams that in-app chat requires. Long polling is not a primary transport in the platform.
However, understanding long polling is useful when integrating Ethora into enterprise environments with strict network policies. Some corporate firewalls block non-standard WebSocket traffic on ports other than 443. Ethora’s XMPP connection runs over standard HTTPS ports, but if a customer’s network still blocks persistent connections, the integration team may need to evaluate supplementary HTTP-based channels for specific notification paths.
