Web-servers work in response to incoming HTTP requests... process the request and return an HTTP response. Are there any common ways that a server can PUSH data to clients in this architecture... e.g a request comes in from client1 and the server wants to notify client2? It can obviously be done by a non-web server, using sockets, but what about a web-server app which has to support page requests AND allow PUSHing data..?
A:
No, not without some client side tech (Flash, Silverlight, Applets, etc.)
You could have the page poll the server with AJAX though.
Eric Petroelje
2010-06-02 12:27:52
Polling is the obvious answer, but how big a performance hit is it if each client keeps sending "are they any updates I should be told?" requests?
John
2010-06-02 12:34:38
@John - Can't really answer that. It would depend entirely on how often you poll, how many clients you have, and how expensive it is to process each request. It would have to be something that you tune over time based on experience with your app.
Eric Petroelje
2010-06-02 12:52:01
+1
A:
You can use web app containers like Jetty which support Web Sockets if you don't mind waiting for the web world to catch up to this up-and-coming standard. Then you'll have real bi-directional communications instead of HTTP + Polling or special plug-ins or the like.
JUST MY correct OPINION
2010-06-02 13:05:21
Sounds cool, but do any browsers support this? And other web-servers than Jetty?
John
2010-06-02 13:12:50
Chrome supports it. I think Firefox does. IE *can* support it with a simple Flash proxy in between (still simpler than doing AJAX and the various Comet tricks).Server-side, I have no idea. Tomcat doesn't support it for sure, but since I use Geronimo+Jetty, I don't care.
JUST MY correct OPINION
2010-06-02 13:31:53
+1
A:
what about a web-server app which has to support page requests AND allow PUSHing data..?
Servlet 3.0 introduces Async support allowing to write Comet style applications (i.e. applications using Long-lived HTTP connections and either long polling or streaming).
If you can't wait for Servlet 3.0 Async support and don't want to use proprietary Comet or WebSocket support from containers (like GlassFish, Jetty), then have a look at Atmosphere.
See also
Pascal Thivent
2010-06-02 13:15:37
@JUSTMYcorrectOPINION: Jetty API **is** proprietary, Resin API **is** proprietary. So container support is proprietary as I wrote. And that's why there is Atmosphere.
Pascal Thivent
2010-06-02 13:50:35
@JUST: You missed a bit: WebSocket support from Java on is nowhere definied in Java EE API. So you're dependent on the container used. It's however indeed a W3C HTML5 standard.
BalusC
2010-06-02 15:29:54
Yeah, I'd spotted that @BalusC, after reading Pascal's reponse. The **support** is proprietary, not the mechanism.
JUST MY correct OPINION
2010-06-02 15:35:26
@BalusC: I think so too, Jean-François (the guy who was behind Grizzly) did IMO a very good job with Atmosphere.
Pascal Thivent
2010-06-02 15:41:15
A:
Another possibility would be to abuse HTTP Keep Alive to achieve this. See http://en.wikipedia.org/wiki/HTTP_persistent_connection for some background. In your scenario you would have client2 initiate a connection to the server that then would stay open listening for notifications.
This is not a great solution, first off you need to keep lots of long lived TCP connections around, and if a connection is lost there is no way for the server to reconnect. It must wait for the client to come back.
Ukko
2010-06-02 13:16:44