5 exercises on long polling vs websockets vocabulary.
0 / 5 completed
1 / 5
How does long polling work?
Long polling: the client sends a request and the server keeps it open until there is data (or a timeout), then responds. The client immediately opens a new request, approximating push over plain HTTP.
2 / 5
What is the main efficiency advantage of WebSockets over long polling?
WebSockets: after one upgrade handshake, a single TCP connection carries messages both ways with minimal per-message overhead, unlike long polling which incurs request/response overhead for each exchange.
3 / 5
When might long polling still be the pragmatic choice?
Long polling fallback: some corporate proxies, old load balancers, or restricted environments block the WebSocket upgrade. Long polling works over standard HTTP everywhere, so libraries use it as a fallback.
4 / 5
A downside of long polling under high message rates is what?
Overhead: each message cycle requires a full HTTP request and response with headers. Under chatty, high-frequency traffic this wastes bandwidth and ties up connections compared to a persistent WebSocket.
5 / 5
WebSockets provide which capability that long polling does not natively?
Full-duplex: WebSockets let client and server send messages independently at any time over the same connection, enabling low-latency interactive apps. Long polling simulates push but is request-driven and half-duplex in practice.