When using server-sent events, how does server communicate to browser that there won't be more events and that it should close the sse connection?
Is this a part of the protocol or should this be implemented by passing hint in normal event to the client that it can close event source ?
The server-sent events is yet another streaming technique which is one of ways of Comet. To stop streaming data, just close the connection in server. You don't need to let client call close method of EventSource instance.
FYI, the following links show that how Cettia streaming transport backed by server-sent events implements to close connection. (Note that I'm an author of Cettia)
Java server - https://github.com/cettia/cettia-java-server/blob/1.0.0-Beta1/server%2Fsrc%2Fmain%2Fjava%2Fio%2Fcettia%2Ftransport%2Fhttp%2FHttpTransportServer.java#L358
JavaScript client - https://github.com/cettia/cettia-javascript-client/blob/1.0.0-Beta1/cettia.js#L884-L886
Edit
For that issue, I added es.close within es.onerror.
Related
Can someone brief about the difference between these looking-similar techniques?
Websocket
Server sent events (SSE)
HTTP2's Server Pushing
I knew all these 3 are "pushing" response from server instead of requesting by the client.
At the first look, it seems all are same.I need to get more clarity about the differences.
Websockets: asynchronous communication in both directions. So far doesn't work well with HTTP/2, but efforts are ongoing to make it so. (For example WISH and websockets2-over-http2.)
SSE: server can notify the browser of events. Uses normal HTTP and works well even with HTTP/2. It's possible to emulate asynchronous communication in both directions with SSE by issuing notifications from client to server via regular POST requests, in HTTP/2 these requests go in the same socket with everything else for the same origin and therefore the cost of establishing a new connection can be avoided. However, there may be processing costs on the server side for processing a POST request which are greater than using native websockets.
HTTP/2 Push: absolutely unrelated to the two above, it is a mechanism for a server to push assets to the browser in advance. Possible application: sending CSSs and Javascripts while the PHP engine is creating the HTML. In theory, HTTP/2 Push and SSE can be combined to make events available to the browser without the initial round-trip delay.
I'm trying to implement a custom live chat program on the web, but I'm not sure how to handle the real-time (or near real-time) updates for users. Would it make more sense to send Ajax requests from the client side every second or so, polling the database for new comments?
Is there a way to somehow broadcast from the database each time a comment is added? If this is possible how would that work? I'm using Sql Server 2008 with Asp.net (c#).
Thanks!
Use long polling/server side push/comet:
http://en.wikipedia.org/wiki/Comet_(programming))
Also see:
http://en.wikipedia.org/wiki/Push_technology
I think when you use long polling you'll also want your web server to provide some support in the form of non-blocking io for requests, so that you aren't holding a thread per connection.
You could have each client poll the server, and at the server side keep the connection open without responding.
As soon there is a message detected at server side, this data is returned through the already open connection. On receipt, your client immediately issues a new request.
There's some complexity as you need to keep track server side which connections is associated with which session, and which should be responded upon to prevent timeouts.
I never actually did this but this should be the most resource efficient way.
Nope. use queuing systems like RabiitMq or ActiveMQ. Check mongoDB too.
A queuing system will give u a publish - subscribe facilities.
I'm developing a chat system and i need to detect the FlexClient disconnect in Java, using the longpolling channel.
I can't use the Streaming channel, because of some bugs that this kind of channel still has. Do you have any suggestion on how could i accomplish this? I'm using BlazeDS.
Regards.
There is no way to detect a client disconnect in real time unless using an RMTP channel which is using behind a socket. When using different channels you can do some workarounds like having some javascript in your web detecting the page unload event, or you can have your client using some kind of heart bit mechanism.
I am using BlazeDS. Does anybody know how to disconnect client from server? Client must be informed about this event.
Thanks for help.
As far as I knew BlazeDS does not support open connections between the Flash Player and the server. You'll have to use LiveCycle if you want to do that.
When you make a server call using the HTTPService, WebService, or RemoteObject tags, there are events that fire when you receive feedback from the server, such as result or fault. When those events fire, you can safely assume that that service call is no longer connected ot the server.
Manytimes clients ask for features like instant messaging (IM) and other client-to-client (P2P) communication for their web apps. Typically how is this done in normal web browsers? For example I've seen demos of Google Wave (and Gmail) that are able to IM from a regular browser. Is this via HTTP? Or does XmlHttpRequest (AJAX) provide the necessary backend for such communication?
More than anything I wonder how can a server "wake up" the remote client, lets say for sending an IM? Or does the client have to keep "polling" the message server for new IMs?
Typically the browser will poll the server for new messages. One approach that is often done to make this more efficient is the 'long poll' (see also this link) - the server responds immediately if it has anything; otherwise, it waits, keeping the connection open for a while. If a message comes in, it immediately wakes up and sends it, otherwise it comes back with a 'nope, check back' after a few tens of seconds. The client them immediately redials to go back into the long-polling state.