I'm looking for a way to send information from a server to a client, for example a song or an image.
Explanation : I want to send a data from my server to the clients who downloaded the HTML5 application.
But I dont know how. I know I can send a php request from the client to the server and answer afterwards, but how could I send something from the server without the client ask it.
Thanks.
You may want to try either Server-Sent Events or WebSockets:
http://www.html5rocks.com/en/tutorials/eventsource/basics/
http://www.html5rocks.com/en/tutorials/websockets/basics/
These technologies allow a client web application to remain open to communication from the server at any time. Server-Sent Events are exclusively server-to-client, whilst WebSockets can be used for bi-directional communication.
Adding to jokeyrhyme's answer...
You want to asynchronously send data from the server to the client. This means the client doesn't know when to expect the data. In practical terms, on today's Web, you have the following options:
Some form of polling, long polling, Comet, etc.
WebSocket
The first option is better understood since those techniques have been around for a long time.
WebSocket is newer but is the better solution as it alleviates the problems that plague HTTP-based techniques with polling, long polling, etc. For a small application, or one that polls infrequently, you can get away with polling. But when you want to scale, those solutions run into problems.
I would not bother with SSE (Server-Sent Events) as that is pretty much a subset of WebSocket. Anyone considering SSE usually ends up just using WebSocket since it's about the same amount of work and it gives you more (e.g. two-way interaction).
However WebSocket doesn't replace HTTP; an application can use both at the same time. Use the right tool for the right job.
In your case, have a client with a WebSocket connection. Then your backend application can notify the client at any time (asynchronously) that there is something to do (e.g. a new song or image is available, as you said in your original post).
I would not bother sending the song or image down the WebSocket connection, although you could. Instead, the client can fetch the song or image using traditional HTTP techniques, which are well understood and good at handling static content. For example, you can take advantage of caching if multiple people are downloading the same (song or image) file.
So, send the id or URL of the song/image to be downloaded via the WebSocket to the client. Then fetch the song/image via HTTP.
That's an example of using both HTTP and WebSocket for their strengths. WebSocket for the efficient asynchronous interaction with virtually no bandwidth consumption, and HTTP for efficient fetching of static resources.
Related
We're trying to update a user, without polling, of an event outside of the scope of what they're doing (for instance, a user has liked one of their posts). Traditionally, we've done this via polling or websockets. I know that HTML5 has push notifications, but it's not exactly what we're looking for (we only want to be able to push a "payload" of data, and not a message, and we don't want to push it to a user that's not on the site).
Is this possible in HTML5 without websockets?
Other than WebSockets, which sound like a perfect fit and the older polling approaches, you might consider SSE (Server Sent Events).
However, WebSockets is generally superior to SSE in many ways (reconnection logic aside) and requires less resources from the browser.
I'm not sure what the limitation on WebSockets might be, but your use case is ideal for a WebSocket connection with a pub/sub backend.
Some time ago I read about some work done to cut down on the web client to web server chatter by combining client requests or server responses to help reduce latency.
Basically the web client would merge its requests into one larger request and/or the server could combine its responses to the webclient into one larger response.
The idea being to reduce chatter and latency in real time.
I am either searching for the wrong thing or just dreaming but my search attempts are coming up empty.
I ask as a developer because I would prefer to enable such a technology rather then having to manually code it myself. We have an app that has the potential to be very chatty.
Search terms I tried are: Request Merging/Combining, Response Merging/Combining, Write Combining for Web, and many others...
Note: I am NOT taking about merging static JS/CSS or even Image files (sprites) at compile time.
A persistent connection enables a client to send multiple requests over the socket. Other possibilities include pipelining and/or WebSocket.
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
I am trying to implement a "Server Push" (or "Reverse Ajax") kind of webpage that will receive updates from the server as and when events occur on the server. So even without the client explicitly sending a request, I need the server to be able to send responses to the specific client browser.
I understand that Comet is the umbrella term for these kind of technologies; with 'Bayeux' being the protocol. But when I looked through the servlet spec, even the 'Async servlet' seems to accomplish the same thing. I mean I can define a simple servlet with the
<async-supported>
attribute set to true in the web.xml; and that servlet will be able to asynchronously send responses to the client. I can then have a jQuery or ExtJS based ajax client that just keeps doing a
long_polling()
call into the servlet. Something like what is described in the link below
http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html#long
So my question is this:
What is the difference between a simple Async servlet and the Comet / Bayeux protocol?
Thanks
It is true that "Comet" is the term for these technologies, but the Bayeux protocol is used only by few implementations. A Comet technique can use any protocol it wants; Bayeux is one of them.
Having said that, there are two main differences between an async servlet solution and a Comet+Bayeux solution.
The first difference is that the Comet+Bayeux solution is independent of the protocol that transports Bayeux.
In the CometD project, there are pluggable transports for both clients and servers that can carry Bayeux.
You can carry it using HTTP, with Bayeux being the content of a POST request, but you can also carry it using WebSocket, with Bayeux being the payload of the WebSocket message.
If you use async servlets, you cannot leverage WebSocket, which is way more efficient than HTTP.
The second difference is that async servlets only carry HTTP, and you need more than that to handle remote Comet clients.
For example, you may want to identify uniquely the clients, so that 2 tabs for the same page result in 2 different clients. To do this, you need add a "property" to the async servlet request, let's call it sessionId.
Next, you want to be able to authenticate a client; only authenticated clients can get a sessionId. But to differentiate between first requests to authenticate and others subsequent requests already authenticated, you need another property, say messageType.
Next, you want to be able to notify quickly disconnections due to network loss or other connectivity problems; so you need to come up with a heart-beat solution so that if the heart beats you know the connection is alive, if it does not beat you know it's dead, and perform rescue actions.
Next you need disconnect features. And so on.
Quickly you realize that you're building another protocol on top of HTTP.
At that point, it's better to reuse an existing protocol like Bayeux, and proven solutions like CometD (which is based on Comet techniques using the Bayeux protocol) that gives you:
Java and JavaScript client libraries with simple yet powerful APIs
Java server library to perform your application logic without the need to handle low level details such as HTTP or WebSocket via annotated services
Transport pluggability, both client and server
Bayeux protocol extensibility
Lazy messages
Clustering
Top performance
Future proof: users of CometD before the advent of WebSocket did not change a line of code to take advantage of WebSocket - all the magic was implemented in the libraries
Based on standards
Designed and maintained by web protocols experts
Extended documentation
I can continue, but you get the point :)
You don't want to use a low-level solution that ties you to HTTP only. You want to use a higher level solution that abstracts your application from the Comet technique used and from the protocol that transports Bayeux, so that your application can be written once and leverage future technology improvements. As an example of technology improvement, CometD was working well way before async servlets came into picture, and now with async servlet just became more scalable, and so your application, without the need to change a single line in the application.
By using a higher level solution you can concentrate on your application rather than on the gory details of how to write correctly an async servlet (and it's not that easy as one may think).
The answer to your question could be: you use Comet+Bayeux because you want to stand on the shoulder of giants.
I am developing a web application that is connected to a server and I need the server to push some information to the clients on a given time.
Therefore I started to read about Server-sent Events (SSE) because the website is been developed on HTML5 and SSE seemed that fit what I was looking for. But what a surprise when I read that what SSE was really doing was sending request FROM the client to the server instead of the opposite way(Yesterday I think I understood that long polling is sort of a push emulation). Therefore I start to read about web sockets (but it seamed that the standard is still a draft) and also had a look to Comet. But I think I cannot fit all the pieces on my mind.
Would someone highlight these technologies (and maybe some other push tec.) that fit my problem and which situation is more appropriate for each one?
Thanks so much, I think I am totally lost on this field.
This post is a better explanation, discussing the difference/advantages/etc, about Long Polling, Comet, SSE and WebSockets.
For the most part, the client usually has to make the first request to the server to establish a connection. Once a connection is established, then the server can push data to the client. So even with WebSockets, the client will make the initial request to the server for establishing a reliable connection between the two.
Server-Sent Events uses a normal HTTP GET request to establish a connection with the server. It's also a read-only connection for the client. It has the benefit of having an easy implementation since we don't have to define a new protocol. The issue is that HTTP connections, even as persistent-connections, are closed after around 15 seconds by most web servers. Even for long standing requests, the web server often has a timeout after which it closes the connection. This is where the idea of long polling comes in. It's a simple idea that we make a normal ajax request to the server and the server leaves it open for as long as possible. If the request is closed by the server for whatever reason, you immediately make the same request again. You can implement a long polling mechanism (ie. Comet) pretty easily with a server such as Node.js and a normal Ajax request from the browser. Server-Sent Events tries to abstract away the browser side implementation of this with EventSource. So instead of you having to implement the browser/client side code for long polling/comet, the browser handles this for you. It provides a nice abstraction of what seems like a persistent connection. Your web server just needs to look out for GET requests which specify the Content-Type, in the header, as "text/event-stream" and leave the HTTP connection open as long as possible.
I would suggest that you don't over complicate what Server-Sent Events are. If you understand a normal HTTP GET request, then you likely already have a 90% understand of the idea behind it.
There is one difference between SSE/Comet and traditional long polling that might be worth highlighting. From my experience, the idea behind long polling is that your request doesn't return until you have an update. At which point the HTTP connection is closed and another request is made immediately afterwards. With SSE, though you can close the HTTP connection right after you send the updated message, your aim is to flush the data from the server to the client without actually closing/ending the HTTP request. This avoids the overhead of actually making a GET request. This can be achieved with a regular ajax request, but again SSE provides a nice/efficient implementation with EventSource.
Edit: clarify distinction between SSE and long polling.
I'm reading about long polling, comet etc and, working on .Net, I read all I have found about SignalR and AspComet. I'm a newbie about comet & similar but it is not clear to me what are the advantages in using SignalR or AspComet where i can simply use jquery.ajax/complete:
(function poll(){
$.ajax({ url: "server", success: function(data){
doSomething();
}, dataType: "json", complete: poll, timeout: 30000 });
})();
but I am clearly missing something here, can you help?
Also, from a system/server point of view what are the main differences? I understand that with $.ajax I open a connection to the server and keep it opened for long (with all the disadvantages of too many open simultaneous connection etc) but I assume SignalR does the same. Or not?
While, on this, AspComet says that it releases the thread back to the request pool.
I know, I'm a bit confused and an intro about the advantages to use SignalR and/or AspComet vs the $.ajax stuff would be greatly appreciated :)
Thanks!
In your $.ajax example you are sending multiple requests to the server and you are doing this for each client. So your web server gets constantly hammered by HTTP requests and only few of them actually serve a purpose because the data that clients have subscribed to notifications for might not change as often. As long as one AJAX request completes another one is sent immediately.
Whereas with long polling you are sending a single request which is blocked by the server and allows it to write to the response and thus notify the client.
The advantage of long polling is that you are limiting the number of HTTP requests sent to your server.
COMET applications often require a custom server. IIS keeps a dedicated thread to handle each request which obviously doesn't scale. There is a limit of a few thousand threads per CPU in IIS.
AspComet solves this problem by providing a server side solution to handle the thread lifetime (like you wrote, it returns the threads back to the pool). AspComet is compatible with the Bayeux Protocol so you can use any Bayeux JS client.
SignalR is a client/server solution that encapsulates the underlying communication protocol in asynchronous calls. SignalR chooses the best protocol available (long polling, websockets or other) so you don't need to worry about it. They have clients for .NET, Silverlight, WP7, JS, etc.