I am starting a long polling request for every page of my website. It looks every second at the database and if there is something new it marks it as seen and outputs the notification. The calling JavaScript is then starting a new ajax request.
Now I got problems having opened multiple tabs on the website, because only one will recieve a new notification. This is also a problem cross-browser with the same username logged in...
What would be the smartest way to solve this fool-proof?
Than you for your input!
I think it is better to avoid browser pulling. You will have browsers problems and also your infrastructure should be huge to support it.
Try a server side pushing tech like Commet,
Comet is a web application model in which a long-held HTTP request
allows a web server to push data to a browser, without the browser
explicitly requesting it.
Other approach could be using WebSockets.
Related
I'm making an app which accesses a database and updates the data every view seconds over a PHP script, the problem is that it currently always updates all data, I would like to know how to program something that dynamically updates data and decides what data to update and what not, so it basically keeps track of change somehow. So how would I best go along doing something like this ?
I think that there should be some where that this question has already be asked but I couldn't find it so maybe someone can show me a website where to look.
In general, you will need to user either XHR requests, web sockets, or HTTP/2 to solve this problem. Since HTTP/2 is not universally supported on the browser side, it may not work for you. Here is the outline of the solution:
Every few seconds, javascript you provide in the browser will need to poll the server for updates using an XHR request. You can use the returned data to update the screen with Javascript. If you only want to do some simple updates, like updating some numbers, you might use raw Javascript or jQuery. If your polling will result in complex screen updates or you want to move a lot of functionality into the client, you probably want to redo your client using one of the JavaScript frameworks like React or Angular.
Use web sockets (or HTTP/2) to create a persistent connection to the server, and have the server send updates to the clients as the data changes. This probably will require some code in the application to broadcast or multicast the updates. The client code would be similar to case 1, except that the client would not poll for updates.
The polling solution is easier to implement, and would be a good choice as long as you don't have too many clients sending polls at too high a rate - you can overwhelm the servers this way.
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'm trying to figure out a way for users of a website (say a student and teacher) to share a secure connection where real time updates on one page are viewed by both of them.
From research I've concluded that some of the real time updates could be performed using ajax and javascript.
But I'm stumped as to how users could share a connection where only the two users would be viewing the updates that take place on the website (such as flash animations of a drawing board.) I'm also confused how you would even begin to set up a connection like this.
I've looked intp php sessions and cookies but I'm not sure I'm doing the right research.
Any pointers as to how two specific users could share a secure connection where real time updates are viewed by the both of them only. I don't want a terse response please. I'm looking for specific details like functions and syntax specific to php. I appreciate the help and will rate you up if you give me good answers!
You cannot share a secure connection (e.g. HTTPS) its one client to one server.
If both clients are logged in and have a background AJAX task running in the browser, is it acceptable to have each client "pull" every few seconds the same data to display for both users?
This would require the "drawing board" updates to also be sent continuously back to the server to share the updated data with the other client. I'm sure there will be an event you can use to trigger the post of data (e.g. on mouse up).
If performance is an issue, you'd want to use a better server technology like Java that is able to keep session state between requests without having to persist to a database.
You can look at ajax push techniques. I used comet once where an administrator posted messages and everybody who was logged in saw that message appear on their screen. I don't know if comet supports PHP. I only used it with JSP. Just search for "ajax push" in Google.
Flash allows for connections between users, I think they refer to them as sockets.
If you want to use Ajax, et al, you need a server side technology that supports push.
Node is the standard in this regard, and you can set up a Heroku instance for free.
There are others, and you need to learn tools before even beginning to learn application.
Among the many overviews, this might interest you:
http://arstechnica.com/business/2012/05/say-hello-to-the-real-real-time-web/?1
A few good examples where this is happening:
Google Docs
Etherpad
HTML5 Games: Multi player
Techniques you can use (with varying browser support)
HTML5 WebSockets (Wikipedia; MDN; HTML5 Demo)
Comet (Wikipedia)
Really pushing data to a web browser client from a server (which would do that when it receives something from another client) is only possible with WebSockets as far as I know. Other mechanism would either require browser plugins or a stand-alone application.
However with Comet (through AJAX) you can get really close to pushing data by polling the server periodically for data. However contrary to traditional polling (e.g. where a clients asks for data every 5 seconds), with the Comet principle the server will hold that periodic request hostage for, say, up to 30 seconds. The server will not send back data until either it has data or the time out is reached. That way, during those 30 seconds, any data that the server receives can be instantly pushed back to the other clients. And right after that the client starts a new 30 second session, and so forth.
Although both Comet and WebSockets should work with a PHP backend served by Apache. I'd recommend looking into NodeJS (as server technology) for this.
There is a lot of information regarding Comet on the internet, I suggest you google it, maybe start at Wikipedia.
The great thing about Comet is that it is more a principle than a technology. It uses what we already have (simple HTTP requests with AJAX), so browser support is very wide.
You could also do a combination, where you use sockets if supported and fallback to Comet.
I'm sure you have looked into this. The opinion that this can be done via ajax is misleading to believe that two users of a website can communicate via javascript.
As you are aware, javascript happens on the client and ajax is essentially 'talking to the server without a page change or refresh'.
The communication between two users of the website has to happen via the server - php and some chosen datastore.
Hope that wasn't terse.
cheers, Rob
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.
I was looking at Twitter Streaming API for getting a real-time feed.
But I dont want it stored on my server.
I just want it pulled from the server and the browser page will retrieve the data from my server's twitter pull URL.
But I want to avoid polling my server every few mill-seconds.
Is there a way for my server script to keep pushing to my browser page ?
Just how live do you want it? There are ways to set up sockets, but they can be fairly complex, and still consume their fair share of bandwidth.
Is it acceptable to poll every 5, 10 seconds or so? Every few milliseconds would give you pretty darn "live" results, but I would not be upset as a user if it took a matter of seconds for something to appear on your website. That would be satisfactorily "live" for me.
Check out COMET.
In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.
I've always wanted to try this method but I haven't gotten around to it:
Hidden IFrame
A basic technique for dynamic web application is to use a hidden IFrame HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible IFrame is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called “forever frame”). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received.[8]
One benefit of the IFrame method is that it works in every common browser. Two downsides of this technique are the lack of a reliable error handling method, and the impossibility of tracking the state of the request calling process.[8]