I would like to check a database for a change using ajax. However, I do not want to overload the server by constantly checking it every second.
Is there any other way of updating the clients from the server?
Can jquery listen for event server side?
Thanks
You could use long-polling. Basically you send a request to the server, and it waits to return with a response. The server will hold the connection until data is available, and it will then return the response containing the data.
For examples of long-polling with Javascript (frameworks), see this question. Additionally, PerplexedLabs did a short tutorial/example of long polling with jQuery and PHP earlier in 2009. You can view it online at http://blog.perplexedlabs...javascript-long-polling/.
Without Flash that is currently not possible. In the future WebSockets will make it possible. Using Flash you can set up a socket connection to the server.
Related
I am writing a simple chat-client (completely intended for learning purposes). My android phone sends messages to a remote MySQL database, and I am in the process of getting the browser to display any new incoming messages.
My current approach is using javascript: it calls a function every 5 seconds, which in turn calls a php that queries for new messages and sends it back to the browser.
I have no experience in ajax, but I've heard it is good when data has to change in a webpage constantly without having to refresh the page, which fits my situation.
My question is, does this sound like something I should use ajax for?
Yes, ajax is the way to go. However, what you have suggested (checking for messages every 5 seconds) generates a lot of requests and bandwidth. You should look into comet, which is still ajax but uses it in a different way.
Comet essentially is this:The client sends a request to the server. The php file on the server has a loop checking every few seconds for a message. When the server finds a message, it echos the message, but it doesn't close the connection. When another message arrives, it echos it again, but doesn't close the connection. This allows it to only need 1 request instead of hundreds. See http://www.zeitoun.net/articles/comet_and_php/start
I'll advice you to go for either ajax or websockets... if you're going for websocket, learn node.js... it has a lot of cool feature as platform built on Google Javascript V8 engine
I am using PHP write the server side of the web page, and javascript to build the client side.
There is a div on the website that will show the data received from server side, for example, Let's say showing the current number of registered users in the databases. This number will keep changing in an unknown period of time. For example, the number could be the same in 10 hours, and it could increment by 1000 in 10 minutes.
My first question is, what is the best approach to do this functionality so that website can always show the latest or almost latest value of this data?
My original approach is using Javascript AJAX and wrapped by setInterval(1000) (-1 second) to send Ajax request to the server side. But I am not sure if this is too heavy for client side (because javascript is single threaded, it might be slow if there is a function running within each 1 second) or even server side( for example, if hundreds of users open this website and hundreds of requests will be sent to server side). So is this ok?
My second question is, if this is not a good approach, what else can I do to achieve the same goal. I was thinking about using the other way around. For example, if there is update in the server side, then use PHP in the server side to push this update to client side, or even directly change the data shown in the HTML using PHP scripting. Is this possible? if it is, is this a good approach?
Any codes or examples provided would be really appreciated.
You can certainly use AJAX for updates that are spread out over time, but if you want to connect to your server every second or so, I would advice against it.
You have a couple of options here:
As #Kay already mentioned, long polling might be an option.
Alternatively, you might want to look into WebSockets or a framework that supports WebSockets, like Meteor
You can use simple long polling.
The client side requests a script "/counter?oldvalue=...×tamp=.... The server does not immediately return a value if it was not changed, but idles for up to 30 seconds.
If the counter value gets changed, then you return the updated value immediately.
How does a server trigger an event on client? For example how in Gmail a popup is appeared when you receive am IM?
You can use Ajax or WebSockets to contact the server, possibly coupled with long-polling to get faster response times (at the price of holding a connection open).
You may use AJAX to achieve a similar effect.
AJAX uses Javascript code to regularly and silently request data from the server. This data may then be used by Javascript to perform some actions.
I want to write a stream that automaticly adds new posts as they come in. I cant see how to do this with Ajax because i would have to request a script every second to keep it updated, and this would overload my server. Can anyone offer any solutions for this? Thanks :)
Overload your server? Are you sure? How many connections you planning on supporting? Make it every 2 seconds and you cut your traffic in half and most likely no one will notice.
Otherwise you're looking at some style of Comet, server side push, with persistent connections to the server.
Refer to:
Long-lived connections (asynchronous server push) with Apache/PHP/Javascript?
You can try XMPP if you want more thing in realtime but if you want only for above requirement then you can try out node.js
You may use the feature of streaming
https://github.com/mojolly/jquery.evented_ajax.js#readme
And actually or better stucture you ajax requests and use some pooling tecniques
http://dev.sencha.com/deploy/ext-4.0-beta2/examples/direct/direct.html
You want Comet long-polling. Comet is so named because like Ajax, it is a brand of detergent.
Comet takes advantage of the fact that browsers can have two open requests to the server. One of these requests is used to push data to the server, say in reaction to UI events happening in the browser.
The other connection is continually connected to the server in a 'long poll'. When the long-polling connection times out or is disconnected, it is automatically re-established by the client (browser).
When the server wants to push data to the client, it immediately writes this data to the waiting long-poll request and ends it, resulting in a more responsive experience than traditional setTimeout() polling with less overhead.
PHP is not ideal for this. Consider Nodejs.
Just like in SO, where one is answering a question, if somebody has answered said question, a notification will appear (via AJAX?). My only way of somewhat replicating this is by including a timeout on my script that fetches if there is an update every n seconds. Is there a way to do this using observer pattern on PHP + Javascript (w/ jQuery)?
you have to look at the ReverseAJAX or COMET methodologies.
As per wikipedia
Reverse Ajax refers to an Ajax design
pattern that uses long-lived HTTP
connections to enable low-latency
communication between a web server and
a browser. Basically it is a way of
sending data from client to server and
a mechanism for pushing server data
back to the browser.
EDIT:
i suggest you to implement the following approach, this is simple to implement. I take stackoverflow answering as an example.
After the answer page load complete. Initiate a AJAX request (Asynchronos, so it wont block the UI)
And it will look for any new updates on the server side (polling the DB to check if any new answers added)
And return the data only to browser, if there is an update. otherwise stay calm.
After returning the data to client, client should invoke the another AJAX request and wait for the updates.
Repeat step 2 to 4 for the rest of the page life time.
Hope this helps.
If you use timeouts to query the server for updates, it may still be considered a peculiar implementation of the Observer pattern. Unfortunately, it's not possible to do it the other way around. If the server finishes responding to the main HTTP request, the client just finishes "listening" to it. The only way to do this is to make an asynchronous request from the client.