What's the best way for keeping the client browser informed about events (like a new chat message)?

Question

The common way, I think, is making a periodic "ping" to the server, but I don't like how it looks too much 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've seen another approach where client ask for news and server "retains" the request (with a sleep loop, for example) until there is anything new. That's cool, but I'd really like to hear about another options.

Answer 1

If this is done with JavaScript, there really isn't any other way than pinging the server. You're only option is to heavily optimize the request, to avoid uselessly asking the "question".

Answer 2

WebSockets can be helpful if you're okay if some browsers aren't able to use it.

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

Answer 3

What you need is ajax push or reverse ajax. There are lots of ajax based frameworks who support push. In Java for example nextapp echo2, or you can give a shot to ape project as well.

Answer 4

Unfortunately there isn't really any cross browser mechanism for pushing data from the server to the browser. For example, back in 1995 Netscape released a server push technology that uses a special content type -- multipart/x-mixed-replace but from what I understand IE doesn't support it. WebSockets are a new one but support is just coming out now.

So you're forced to use the tools at hand, which means the client needs to ask the server if there's any new data -- polling. Polling comes in 2 varieties: polling on an interval, and long polling. When you poll on an interval you simply make a request to the server every n seconds asking for data. This is fairly chatty (pardon the pun) if there is no new data to return. This is what people think of when you say "polling."

The other option, long polling, is similar in that the client makes a request to the server to see if there's new data. But in this case the server doesn't send a response until it has something to say. In this case the client is left hanging for a response for an undetermined amount of time. When the client eventually gets its response it parses the response and immediately makes another request which will stay hanging until there's data.

Both of these polling approaches consume a lot of HTTP overhead, but if you want to use XHRs this is about the only way to do it.

A word of warning about long polling: When working with long polling it's important to ensure that all of your XHRs are running asynchronously otherwise you'll see the browser's UI thread lock up.

---

If you're not interested in using AJAX then you can always use the tried and testing IFRAME-that-never-finishes-loading. In this case you have an IFRAME with the chat log and another IFRAME that contains your message area. In this case the server simply never closes the connection for the IFRAME that contains the chat log. Instead, it just keeps pushing chat messages into the body.

Answer 5

Options

• Long-Polling: keep the request open until data arrives. Receive data and close connection. Open a new connection to receive data again. For this to scale you need to have non-blocking IO)for all communication). This approach is the simplest to implement. You could 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. For this to work cross-browser you have to do some "hacking" to make it work in all browsers.
• XMPP over BOSH For this you use your XMPP server and sprinkle it with some BOSH(XMPP over HTTP). Prosody for example is an easy XMPP server which supports BOSH. Next you could write the client-side with the excellent strophe.js library.
• Websockets: I guess this will be the future, but right now the browser support is not sufficient to really use it for all browsers.
• Server-Sent Events: Also pretty cool html5 feature. This protocol is in my opinion simpler then websockets. This also is not widely supported by all the majar browsers yet.
• Flash: You could also communicate via flash if you like. The browser has to have flash plugin installed, but that will be the case most of the times.

What is the best way?

1. In my opinion long-polling is the easiest/best way to implement event-based messaging over HTTP. it definitely is not the fastest alternative, but every major browser supports it and the easiest to implement.
2. I think Websockets will be the best technology(future), but is not widely adopted in the browsers yet.
3. All though all the above technologies are pretty good. They all have there pros and cons.