After reading this post (probably, you can get the gist by looking at the images, no need to read the whole text), I'm having a hard time deciding at which point is needed the help of comet type technologies.
It looks to me (naively) that all of that can be accomplished by using ajax requests and a database to retrieve several versions. Is that true?.
Probably I'm missing something, so a clarification would be great.
UPDATE:
Given the helpful answer written by Andrew, saying that an ajax approach to this issue it is not timely, I was wondering why, that is, at which stage the response sent by the server to the client will produce a delay?.
Comet IS Ajax requests.
In order for the server to be able to push notifications to the users browsers(IE anytime you see the server sending a change in the diagrams), the user needs to have a connection with the server already. The method of maintaining that connection using ajax long polling or the like is what the term comet refers to.
Yes, you could implement this by sending an Ajax request every x seconds. But that is wasteful, and it is not timely.
[Edit]
When I say it's not timely, what I am saying is that, using an ajax call to update on an interval will have a delay of whatever that interval is.
The server CANNOT send an update to the client. It can only answer requests from the client. So if the server gets new information, it has to sit on it until all the clients come back and ask for an update. In a scenario like this people can edit the same information and commit it at the same time, which needs to be handled by the server, and which is what the article is addressing. Using a comet framework will just reduce the chances of this happening because the different clients will be better synced.
Related
I've seen how to make a post request from JavaScript to get data from the server, but how would I do this flipped. I want to trigger a function in the flask server that will then dynamically update the variable on the JavaScript side to display. Is there a way of doing this in a efficient manner that does not involve a periodic iteration. I'm using an api and I only want to the api to be called once to update.
There are three basic options for you:
Polling - With this method, you would periodically send a request to the server (maybe every 5 seconds for example) and ask for an update. The upside is that it is easy to implement. The downside is that many requests will be unnecessary. It sounds like this isn't a great option for you.
Long Polling - This method means you would open a request up with the server and leave the request open for a long period of time. When the server gets new information it will send a response and close the request - after which the client will immediately open up a new "long poll" request. This eliminates some of the unnecessary requests with regular polling, but it is a bit of a hack as HTTP was meant for a reasonably short request response cycle. Some PaaS providers only allow a 30 second window for this to occur for example.
Web Sockets - This is somewhat harder to setup, but ultimately is the best solution for real time server to client (and vice versa) communication. A socket connection is opened between the server and client and data is passed back and forth whenever either party would like to do so. Javascript has full web socket support now and Flask has some extensions that can help you get this working. There are even great third party managed solutions like Pusher.com that can give you a working concept very quickly.
I want to create a web application that displays data from a public api. I will use d3 (a javascript data-visualization library). I want to retrieve data from the api every ten minutes, and update my page (say it is traffic, or something). I have not built many web applications, how do I get the updates?
Should the js on the client side use a timer to request updates from the server side of my application (perhaps the application is written in Rails or node.js). The server then makes the api call and sends a response asynchronously? Is this called a socket? I have read that HTML5 provides sockets.
Or, perhaps an AJAX request?
Or, does the server side of my application create a timer, make the api call, and then "push" updates to the view. This seems wrong to me, there could be other views in this application, and the server shouldn't have to keep track of which view is active.
Is there a standard pattern for this type of web application? Any examples or tutorials greatly appreciated.
An AJAX request (XMLHttpRequest) is probably the way to go.
I have a very simple example of an XMLHttpRequest (with Java as the backend) here: https://stackoverflow.com/a/18028943/1468130
You could recreate a backend to receive HTTP GET requests in any other server-side language. Just echo back whatever data you retrieved, and xmlhttp.onload() will catch it.
Depending on how complex your data is, you may want to find a JSON library for your server-side language of choice, and serialize your data to JSON before echoing it back to your JS. Then you can use JavaScript's JSON.parse() method to convert your server data to an object that can easily be used by the client script.
If you are using jQuery, it handles AJAX very smoothly, and using $.ajax() would probably be easier than plain-old XMLHttpRequest.
http://api.jquery.com/jQuery.ajax/
(There are examples throughout this page, mostly-concentrated at the bottom.)
It really annoys me how complicated so many of the AJAX tutorials are. At least with jQuery, it's pretty easy.
Basically, you just need to ask a script for something (initiate the request, send url parameters), and wait for the script to give you something back (trigger your onload() or jqxhr.done() functions, supplying those functions with a data parameter).
For your other questions:
Use JavaScript's setTimeout() or setInterval() to initiate an AJAX request every 600000 milliseconds. In the request's onload callback, handle your data and update the page appropriately.
The response will be asynchronous.
This isn't a socket.
"Pushing" probably isn't the way to go in this case.
If I understand correctly and this API is external, then your problem can be divided into two separate sub-problems:
1) Updating data at the server. Server should download data once per N minutes. So, it should not be connected to customers' AJAX calls. If two customers will come to the website at the same time, your server will make two API call, what is not correct.
Actually, you should create a CRON job at the server that will call API and store its' result at the server. In this case your server will always make one call at a time and have quite a fresh information cached.
2) Updating data at clients. If data at customers' browsers should be updated without refreshing the page, then you should use some sort of Ajax. It can make a request to your server once per X minutes to get a fresh data or use so-called long-polling.
I think the most effective way to implement real time Web application is to use Web socket to push changes from the server rather than polling from the client side. This way users can see changes instantaneously once server notify that there is new data available. You can read more on the similar post.
I have tried using nodejs package called socket.io to make a real time virtual classroom. It works quite well for me.
I want to implement web site that will display to user a notification about some event happened on server. My plan is:
to make an asynchronous request to the server (ASP.NET) which will have a 600 seconds time-out
if event occurs on the server in the time interval of these 600 seconds server will response with an event details
if event is not occurred the server then server will send an 'no event' response at the end of 600 seconds
JS upon receiving a feedback from server will process the response and send the next request.
The problem of the approach is that for a big amount of visitors web site will have a lot of 'pending' requests.
Questions:
Should I consider that as a problem? What is solution for that? Probably I should implement another approach?
Please advice, any feedback is welcome.
I don't know specifics about asp.net's handling of pending requests, but what you are describing is basically long-polling. It's tricky for a number of reasons, including but not limited to:
each pending request consumes a thread, and you'll need to store state on each of those threads
if you have enough connections (not necessarily all that many; see above), you'll need them to span multiple machines, and you then need to come up with an architecture to distribute endpoints across those machines, and make sure each incoming request goes to the right machine. If you're only broadcasting the same data to all your users, this becomes much easier.
proxies or ISPs or what-have-you may shut down your long-poll request. You'll need an architecture resilient to that.
Here's a question about long-polling in asp.net: How to do long-polling AJAX requests in ASP.NET MVC? It's probably a good place to start.
Also you could consider a 3rd-party service like pusher to handle these connections for you, or (disclaimer: I work on App Engine) App Engine's Channel API.
Surely you could make more frequent requests to the server that do not consume server resources for 10 whole minutes?
e.g. send an AJAX request every 60 seconds or so, and return whether or not any event has occurred. The downside is that it could take up to a minute for a user to see notification about some event, so if you need it more or less immediately, that is a problem.
If it does have to be immediate, it seems like looking into "long polling" with something like node.js might be a solution, though non-trivial to implement.
Google's GMail service does it because it integrates Google Talk -- and Etherpad (now typewith.me) made famous the system which is used by, for example, Google Wave. All such systems update the page the user is working on effectively instantly when other users make changes to the page. It's easy to tell the server that a change has happened when it has happened, but it's more difficult to get clients to update themselves.
How does this kind of realtime editing work? Does it simply have the client ping the server tens of times per second for updates?
You can use Comet.
Asynchronous JavaScript and XML or AJAX
With Ajax, web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. The use of Ajax techniques has led to an increase in interactive or dynamic interfaces on web pages. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not actually required, nor do the requests need to be asynchronous.
Just in case someone falls on that question.
Comet was an old way of doing real-time updates, now it has been made obsolete by technologies like websockets
I suggest using AJAX & jQuery for Asynchronous JS
http://api.jquery.com/category/ajax/
There are many options but basically i'd recommend you look into XMPP. i don't think i'm good enough to boil it down correctly, so i'll let a wiki talk for me
In fact, google voice and video uses it for these systems.
About AJAX, i think it's a communication channel, not a platform or a protocol for multiple person exchange. You could also answer "Use xml over http!" and still be at the same point :)
AFAIK, they use some form of AJAX. However, I would recommend you use the AJAX libraries via jQuery. AJAX is simplified a lot if you use jQuery to do it.
Javascript / Ajax allows you to send code to be executed on the client-side (that means, by the browser).
Now if you e.g. define a loop which checks for new messages on server every 5 seconds, you can update the web-page "in-real-time" (plus the time for the server to process the req and send response), or similar. A practical example would be the RoR Prototype periodically_call_remote Ajax helper.
Hope this helps!
As everyone says.. AJAX.
The client keeps on asking the server, after say 30 secs if there is anything new for it to do. Also, you can set the timeout value on an ajax request. keep the time out a bit high.. and the server replies whenever there is something new.
There is no way that the server can other wise ask the client to load some data.
If you are thinking of implementing something on the same lines, look up strophe.js which is an XMPP js-library
It can be done via POlling and Push design.
Polling is a client side information pulling technique after a given timeperiod.
Push technique involves the server to push the new updates to the client using websockets or new websocket like technology for example pusher.
Article
I'm trying to reverse engineer how facebook handles their notifications, where when you get a message you get instantly notified via the browser.
I've fiddled with it for a little bit and realized that there is always a pending GET request "listening" if you will to some sort of update from the server. This appears to be some sort of observer pattern. I was just wondering if this pattern was documented somewhere.
The technique is actually called Long Polling. This is one of the popular Comet techniques to get around the limitations of traditional polling.
You may want to check out the following Stack Overflow post for a very simple example:
Simple “Long Polling” example code?
UPDATE:
In addition to the above, I suggest that you check out the accepted answer to the following Stack Overflow post for a detailed description of the technique:
How does facebook, gmail send the real time notification?
The technique is called Comet, aka 'server push'
There are currently 2 main ways of implementing comet.
1) As Daniel mentioned, long-polling, where you can use ajax to leave a hanging request to the browser that doesn't send the response back until the server decides to (whether it be based on someone else's actions or another server event).
2) The second approach, used by Google, is streaming. This involvs using ajax to leave a hanging request, but the response is never sent back to you, ever. Instead, the server updates bits of data and you use javascript to monitor changes, and fire events based on new data being pushed in. What happens is you get one very long continuous stream of data flowing in on a document that never closes, taking new data as it comes in.
HTML5 has a specification for a simpler way to do this with Web-Sockets. In the future, this type of live web-app will become commonplace as Web-Sockets are easy to use, but it is not supported on all browsers yet.
If you want to build a Comet site for production, you'll need to use a non-blocking I/O async server like one of the following.
http://www.tornadoweb.org/ - python
http://nodejs.org/ - server side javascript
-- or google for comet servers.
You'll need to know how to program for comet type apps on the server-side, as the javascript for Comet is pretty trivial, just your normal ajax calls with a couple event handlers.