Because of a frequent losing of websoket connection between client and server, is this a good idea to use Vaadin 23 WEBSOCKET_XHR + ui.setPollInterval() as a backup channel?
For example:
var ui = UI.getCurrent();
ui.setPollInterval(500);
listenableFuture.addCallback(result -> {
ui.access(() -> {
// some ui updates
ui.setPollInterval(-1);
ui.push();
});
Theoretically, in case the push will not deliver changes to the client, the client will pull the changes via XHR call. Does such setup make sense?
It seems a bit pointless to me.
If you're using polling, there's no sense in using ui.push(), as Server Push is only needed when there is no request from the client. With polling enabled, the client sends requests periodically (in your case, every 500 milliseconds after the arrival of the last response). So you're getting no benefit from the actual Server Push as the client is polling the server every 0.5 seconds already.
Related
Right now, I'm pulling some 10 kB sensor data from a server via a single plain old HTTP request every 5 minutes. In the future, I might want to increase the frequency to make one request every 30 seconds.
When does server-side push technology become necessary?
Obviously, the precise answer depends on the server - but what's the general approach to the issue? Using push technology definitely seems advantageous. However, the would have to be some major code rewriting. Additionally, I feel like 30 seconds is still a long enough interval and the overhead (e.g. cookies in HTTP headers, ...) shouldn't cause too much surplus traffic.
Push technology is useful for any of the following situations:
You need the client to have low latency when there is new data (e.g. not wait for the next polling interval, but to find out within seconds or even ms when there is new data).
When you're interested in minimizing overhead on your server or bandwidth usage or power consumption on the client, yet the client needs to know in a fairly timely fashion when new data is available. Doing frequent polling from a mobile client chews up bandwidth and battery.
When data availability is unpredictable and a regular polling would usually result in no data being available. If every poll results in data being collected and the timeliness of a moderate polling interval is sufficient for your application, then there are not big gains by switching to a push notification mechanism. When the poll usually results in an empty request, that's when polling becomes very inefficient.
If you're sending data regularly and you are trying to minimize bandwidth. A single webSocket packet is way more efficient than an HTTP request as the HTTP request includes headers, cookies, etc... that need not be send with a single webSocket packet once the webSocket connection has already been established.
Some other references on the topic:
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
websocket vs rest API for real time data?
Cordova: Sockets, PushNotifications, or repeatedly polling server?
HTML5 WebSocket: A Quantum Leap in Scalability for the Web
I am not sure what are the advantages for using Faye or some other push system and not use Ajax for it.
Specifically I mean for implementing chat and notification functionality.
If I make a chat message model, and in my post ( which has many chat messages) , in the post page I can use Ajax to refresh the messages and I get the chat functionality.
Am I missing something on Faye or with Ajax?
Is it more efficient?
Faye is establishing a connection that the server can push data to the client with. With Ajax the client must request data and if it doesn't know that new data is available (which is the case in a chat client) then it must poll periodically for new content.
Is it more efficient? If the chat system sees enough traffic that your poll period is getting new data every time, probably not. If, on the other hand, you have an idle chat room then all of that polling is going to be chewing up resources that could be avoided by having the server push the data.
The flip side of this is that you are keeping a connection open with the server. This could work against you if you have a large number of idle clients. Because of this, it would be context sensitive as to which approach is better, or perhaps even a hybrid approach (opening a Faye connection for active use and then idling out to Ajax polling on an infrequent basis).
Ian Hickson says:
I expect the iframe sandboxing feature
will be a big boon to developers if it
takes off. My own personal favorite
feature is probably the Web Sockets
API, which allows two-way
communication with a server so that
you can implement games, chatting,
remote controls, and so forth.
What can you get with web sockets that you can't get with AJAX? Is it just convenience, or is it somehow more efficient? Is it that the server can send data to the client, without having to wait for a message so it can respond?
Yes, it's all about the server being able to push data to the client. Currently, simulating bi-directional communication without Flash/Silverlight/Java/ActiveX takes the form of one of two workarounds:
Traditional polling: Clients make small requests to the server frequently, checking for updates. Even if no update has occurred, the client doesn't know that and must continuously poll for updates. Though each request may be lightweight, constant polling by many clients can add up quickly.
Long polling: Clients make periodic requests for updates, like regular polling, but if there are no updates yet available then the server does not respond immediately and holds the connection open. When an update is finally available, the server pushes that down to the client, which acts on it and then repeats that process. Long polling offers push-like update resolution, but is basically a self-inflicted DDoS attack and can be very resource intensive for many types of web servers.
With WebSockets, you get all of the responsiveness advantages of long polling, with dramatically less server-side overhead.
WebSockets are more efficient (and "more real-time") than AJAX calls because you keep connection open and don't send extra protocol headers and other stuff after each request and response. Look at this article:
During making connection with
WebSocket, client and server exchange
data per frame which is 2 bytes each,
compared to 8 kilo bytes of http
header when you do continuous polling.
I'm working on a web application that submits tasks to a master/worker system that farms out the tasks to any of a series of worker instances. The work queue master runs as a separate process (on a separate machine altogether) and tasks are submitted to the master via HTTP/REST requests. Once tasks are submitted to the work queue, client applications can submit another HTTP request to get status information about tasks.
For my web application, I'd like it to provide some sort of progress bar view that gives the user some indication of how far along task processing has come. The obvious way to implement this would be an AJAX progress meter widget that periodically polls the work queue for status on the tasks that have been submitted. My question is, is there a better way to accomplish this without the frequent polling?
I've considered having the client web application open up a server socket on which it could listen for notifications from the work master. Another similar thought I've had is to use XMPP or a similar protocol for the status notifications. (Of course, the master/worker system would need to be updated to provide notifications either way but I own the code for that so can make any necessary updates myself.)
Any thoughts on the best way to set up a notification system like this? Is the extra effort involved worth it, or is the simple polling solution the way to go?
Polling
The client keeps polling the server to get the status of the response.
Pros
Being really RESTful means cacheable and scaleable.
Cons
Not the best responsiveness if you do not want to poll your server too much.
Persistent connection
The server does not close its HTTP connection with the client until the response is complete. The server can send intermediate status through this connection using HTTP multiparts.
Comet is the most famous framework to implement this behaviour.
Pros
Best responsiveness, almost real-time notifications from the server.
Cons
Connection limit is limited on a web server, keeping a connection open for too long might, at best load your server, at worst open the server to Denial of Service attacks.
Client as a server
Make the server post status updates and the response to the client as if it were another RESTful application.
Pros
Best of every worlds, no resources are wasted waiting for the response, either on the server or on the client side.
Cons
You need a full HTTP server and web application stack on the client
Firewalls and routers with their default "no incoming connections at all" will get in the way.
Feel free to edit to add your thoughts or a new method!
I guess it depends on a few factors
How accurate the feedback can be (1 percent, 5 percent, 50 percent) Accurate feedback makes it worth pursuing some kind of progress bar and comet style push. If you can only say "Busy... hold on... almost there... done" then a simple ajax "are we there yet" poll is certainly easier to code.
How timely the Done message has to be seen by the client
How long each task takes (1 second, 10 seconds, 10 minutes)
1 second makes it a bit moot. 10 seconds makes it worth it. 10 minutes means you're better off suggesting the user goes for a coffee break :-)
How many concurrent requests there will be
Unless you've got a "special" server, live push style systems tend to eat connections and you'll be maxed out pretty quickly. Having to throw more webservers in for a fancy progress bar might hurt the budget.
I've got some sample code on 871184 that shows a hand rolled "forever frame" which seems to work out well. The project I developed that for isn't hammered all that hard though, the operations take a few seconds and we can give pretty accurate percent. The code uses asp.net and jquery, but the general techniques will work with any server and javascript framework.
edit As John points out, status reporting probably isn't the job of the RESTful service. But there's nothing that says you can't open an iframe on the client that hooks to a page on the server that polls the service. Theory says the server and the service will at least be closer to one another :-)
Look into Comet. You make a single request to the server and the server blocks and holds the connection open until an update in status occurs. Once that happens the response is sent and committed. The browser receives this response, handles it and immediately re-requests the same URL. The effect is that of events being pushed to the browser. There are pros and cons and it might not be appropriate for all use cases but would provide the most timely status updates.
My opinion is to stick with the polling solution, but you might be interested in this Wikipedia article on HTTP Push technologies.
REST depends on HTTP, which is a request/response protocol. I don't think you're going to get a pure HTTP server calling the client back with status.
Besides, status reporting isn't the job of the service. It's up to the client to decide when, or if, it wants status reported.
One approach I have used is:
When the job is posted to the server, the server responds back a pubnub-channel id (one could alternatively use Google's PUB-SUB kind of service).
The client on browser subscribes to that channel and starts listening for messages.
The worker/task server publishes status on that pubnub channel to update the progress.
On receiving messages on the subscribed pubnub-channel, the client updates the web UI.
You could also use self-refreshing iframe, but AJAX call is much better. I don't think there is any other way.
PS: If you would open a socket from client, that wouldn't change much - PHP browser would show the page as still "loading", which is not very user-friendly. (assuming you would push or flush buffer to have other things displayed before)
Obviously, you can't push data to a web application, as HTTP works in a request-response cycle.
But what hacks/methods do you know of that can imitate pushing data to a client?
You could use what is known as Comet:
http://en.wikipedia.org/wiki/Comet_(programming), https://stackoverflow.com/search?q=comet
Basically, javascript in the browser makes a request to the server right away (using XmlHttpRequest). The server does not respond until it has some data to serve.
From the article:
The browser makes an asynchronous request of the server, which may wait for data to be available before responding. The response can contain encoded data (typically XML or JSON) or javascript to be executed by the client. At the end of the processing of the response, the browser creates and sends another XHR, to await the next event. Thus the browser always keeps a request outstanding with the server, to be answered as each event occurs.
In some instances polling i.e. sending a request at a regular (short) interval might suffice. But the answer given above - Comets - is the closest thing to the real deal as far as sending data without a client request is concerned.
You're limited to polling in HTTP. One of the early Netscape browsers did implement HTTP push I seem to recall, back at the start of the century but it didn't get anywhere.
Good ol' Wikipedia page on HTTP Push (with lots of [clarification needed])
You can't use raw sockets with Flash, Javascript/Xml, Silverlight. With Java, and Active-X you can, but you'll need a certificate. The Quake Live shows this off, all the networking is obviously still UDP based but inside a browser plugin for IE or Firefox.
So polling, polling, polling.