1How WebIM Implements Message Pushing
WebIM typically has three methods to implement a push channel:
-
WebSocket
-
FlashSocket
-
HTTP Polling
Among these, ① and ② are implemented using TCP long connections, which can guarantee the real-time nature of messages through TCP. Scheme ③ is considered the “orthodox” method for WebIM to implement message pushing, using HTTP short connection polling to achieve a “pseudo-long connection.” Since it is polling, some may question the real-time nature of the messages. This article aims to clarify how WebIM uses HTTP long polling to ensure absolute real-time messaging.
2Why Do People Misunderstand HTTP Long Polling as Not Real-Time?
What is polling? This is a bit tricky to explain. For example, if you want to use the restroom on a train, you squeeze your way to the restroom door, only to find it occupied, so you have to return to your seat and wait. After N minutes, you squeeze your way back to the restroom, only to find it still occupied, and you have to return to your seat again. This repeated checking every N minutes to see if the restroom is available is polling.
What problems arise when WebIM uses polling to fetch messages? WebIM polls the “get messages” interface every N minutes, which may lead to message delays. At a certain moment, if a new message arrives just after the last polling, that message will have to wait until the next polling after N minutes to be retrieved.
Can reducing the polling interval solve the message delay issue? Reducing the polling interval can indeed shorten the delay time, but it cannot guarantee absolute real-time messaging, and it introduces new problems. Most polling calls return no messages, leading to significant resource waste on the server side.
Many people intuitively believe that WebIM’s use of HTTP long polling for message retrieval will cause delays, but in fact, WebIM’s HTTP long polling does not work that way.
3How Long Polling Actually Works
Message Connection A dedicated HTTP connection is established between WebIM and the web server for message transmission, referred to as the HTTP message connection (see the diagram below).
Four Key Features of the Message Connection
-
When no messages arrive, this HTTP message connection will be held open without returning. Since HTTP is a short connection, this HTTP message connection can be held for a maximum of 90 seconds before being closed (this is the behavior of the browser or web server).
-
In case ①, if the HTTP message connection is closed, a new HTTP message connection is immediately initiated (see steps 1 and 2 in the diagram below).
-
With the combination of ① and ②, there will always be a message connection between the browser and the web server (in extreme cases, ④ may occur). Each time a message is received, this message connection can promptly bring the message back to the browser page, and immediately after returning, a new HTTP message connection is initiated (see steps 1, 2, and 3 in the diagram below).
-
If a message arrives while the previous HTTP message connection is still returning, and no HTTP message connection is available (theoretically, the return of the HTTP message connection is instantaneous, so the probability of no available connection is very low), the message will be temporarily stored in a message pool. When the next message connection arrives (after the previous message connection returns, based on ② and ③), it will immediately return the new message connection without any waiting time, bringing the message back and immediately generating a new message connection (see steps 1, 2, 3, 4, 5, 6, 7 in the diagram below).
Steps 1-4 above ensure that there is always an HTTP message connection open, guaranteeing the absolute real-time nature of WebIM message pushing.
Conclusion
WebIM can guarantee the absolute real-time nature of messages through HTTP long polling. This real-time guarantee is not achieved by increasing the polling frequency but by holding the HTTP message connection open. During most times without real-time messages, this HTTP message connection places a request pressure of once every 90 seconds on the web server, significantly saving web server resources.
