What is the best way to inform the client browser about events (for example, a new chat message)?

Question

The usual way, I think, makes periodic "ping" for the server, but I don’t like the way it looks too, like

"Is there anything new? - No" "Is there anything new? - No" "Is there anything new? - No" "Is there anything new? - No" "Is there anyt..." 

I saw a different approach when a client requests news, and the server “saves” the request (for example, with a sleep cycle) until something new appears. That's cool, but I'd love to hear about other options.

Answer 1

Unfortunately, there is actually no cross-browser mechanism for transferring data from the server to the browser. For example, back in 1995, Netscape launched a push server technology that uses a special type of content - multipart / x-mixed-replace, but from what I understand, IE does not support it. WebSockets are new, but support is just coming out.

So, you are forced to use the tools at hand, which means that the client must ask the server if there is new data - a survey. The survey takes place in 2 variants: intermittent interrogation and long interrogation. When you poll at intervals, you simply make a request to the server every n seconds, requesting data. This is rather talkative (pardon pun) if there is no new data to return. This is what people think when you say "survey."

Another option, a lengthy survey, is similar to the fact that the client makes a request to the server to see if there is new data. But in this case, the server does not send a response until it has nothing to say. In this case, the client remains suspended to respond for an indefinite period of time. When the client ultimately receives the response, he analyzes the response and immediately makes another request, which will remain hanging until the data appears.

Both of these polling approaches consume a lot of HTTP resources, but if you want to use XHR, this is the only way to do this.

Warning about long polling: when working with long polling, it is important to make sure that all of your XHRs are started asynchronously, otherwise you will see a blockage in the browser user interface stream.

---

If you are not interested in using AJAX, you can always use the tried and tested IFRAME-this-never-ending download. In this case, you have an IFRAME with a chat log and another IFRAME that contains your message area. In this case, the server simply never closes the connection for the IFRAME, which contains the chat log. Instead, he simply continues to push chat messages into the body.

Answer 2

WebSockets can be useful if you are fine, if some browsers cannot use it.

If you want this in JavaScript, there is no alternative to polling at intervals.

Answer 3

You need ajax push or reverse ajax . There are many ajax-based frameworks that support push. In Java, for example, nextapp echo2, or you can take a snapshot of the ape project .

Answer 4

Functions

• Long-Polling : open a request before receiving data. Get data and close the connection. Open a new connection to receive data again. For this to scale, you need to have a non-blocking IO) for all messages). This approach is the easiest to implement. You can even use blocking I / O if your server does not have a lot of concurrency.
• HTTP Streaming . Do not close the connection when receiving data. To do this, in order to work in a cross browser, you need to do some “hacking” to make it work in all browsers.
• XMPP over BOSH To do this, you use your XMPP server and sprinkle it on some BOSH (XMPP over HTTP). For example, prosody is a simple XMPP server that supports BOSH. Then you can write the client side with the excellent strophe.js library.
• Web sites I suppose this will be the future, but right now the browser support is not enough to really use it for all browsers.
• Events with the server . Also a pretty cool html5 function. This protocol, in my opinion, is simpler than websockets. It is also not widely supported by all majar browsers.
• Flash You can also chat via flash if you want. The browser must have the Flash plugin installed, but this will be the case in most cases.

What is the best way?

• In my opinion, a lengthy survey is the easiest / best way to implement HTTP messaging. this is definitely not the fastest alternative, but every major browser supports it and is easiest to implement.
• I think Websockets will be the best technology (future), but not yet accepted in browsers.
• All, although all of the above technologies are pretty good. All have pros and cons.

Answer 5

If this is done using JavaScript, there really is no other way but to ping the server. You are the only option - it is strongly optimize the request in order to avoid the useless request of the "question".