Today, when I was using Google+ in two separate browsers, I posted something with one browser. The post almost instantly appeared on the second browser (there was maybe 0.5 seconds of delay). How does Google achieve this? Do they constantly send AJax requests to check for new posts? Wouldn't this put a lot of strain on the server?
There are a variety of methods can be used to do this:
Websockets
AJAX Long-Polling
page timers
iframes
Each one has it's own caveats and possibilities.
If you're interested in being able to do a real-time application, you might have a look at socket.io which is a great abstraction library for all of these technologies, so it'll use the one which is best supported in your browser.
Can't say how Google does it exactly for sure, but they would have to be using some sort of push technology. HTML5 WebSockets is something that can do this in newer browsers. In older browsers that don't support websockets, the client usually polls the server periodically. See socket.io for a neat cross-browser implementation of WebSockets, with fallbacks to other methods if the browser doesn't support it, documented here.
I suppose one technique they could use is to send an AJAX request immediately and then block it on the server side until a timeout or content is available to be sent.
For years google was using Comet or Reverse Ajax: http://en.wikipedia.org/wiki/Comet_(programming))
However, I believe they are using HTML5 WebSocket now that the API is ready:
http://en.wikipedia.org/wiki/WebSocket/
http://dev.w3.org/html5/websockets/
Related
I have a web application and I need the user to be able to see wether a notification for them has landed. I want the notification icon to change it's state when they have a new one.
Basically, I want to listen when the API endpoint updates it's state for the current user and the front end to change it's state.
I thought of make that endpoint as an observable and the front end as an observer, but I don't know if that fits in what I need.
Any ideas?
I'd suggest to use a web socket implementation, such as Socket.io.
Although there are many alternatives to Socket.io, its major advantage is that it provides multiple fallbacks for older browsers. So, e.g. if web sockets are not available or do not work, it tries AJAX long polling. This way you can even support browsers that were created at a time, when nobody even knew what web sockets are - but to you, the API stays the same.
If you know that you only have to deal with modern browsers, you may use a more lightweight alternative instead, e.g. ws.
If you are looking for something completely different, which is purely based on HTTP and does not require an additional protocol, you might be interested in HTML5 Server-sent events. They work great, but in contrast to web sockets they are not bidirectional, and they are currently not supported in IE and Edge. They also have some other disadvantages. For example, it's not possible to add custom headers to an SSE request.
With HTTP2 it's maybe questionable how much impact web sockets will still have in the future, especially if you take into account that things such as the Streams API are coming. Then, you could basically solve everything using pure HTTP, which has some advantages as well. But right now, the Streams API is not here, so let's wait and see…
I built a notification system that checks whether there are new notifications every 10 seconds using the setInverval javascript function, that sends ajax request and returns a json with the notifications.
I would like to hear alternative ways to do that, that doesn't have to be timed.
Is a while loop & a worker thread better?
Since I'm working with PHP, how do I not overload the server with too many requests?
What are the security risks I am facing with my system, and with the system you'd like to suggest.
If you're not satisfied with your current mechanism, look into the cluster of various mechanisms collectively called "comet" and/or web sockets depending on the browser profiles you have to support (IE8 and 9 don't have web sockets, for instance). There are several libraries out there to help you with this, such as socket.io.
I don't think the security profile changes either way, but that would probably be a separate question in any case.
I'm working on a project where a page, needs to be able to keep updated according to the state of a server.
I like websockets for this since they offer me a way of pushing messages from the server, but availability is a problem.
I need generic way to do two way communication between a webserver and a browser-client.
I would like to be able to hold a large amount of clients on my server, so busywaiting clients is not a good solution.
I've looked at long pooling, but this seames like busy waiting on the clients part -- is it the only way to go if I need IE support?
This question is only about the clients end of the transactions.
Do you need two-way communication? If not you should use SSE (Server-sent Events). They are also easier to simulate in IE (as SSE actually degrades gracefully to long-polling on older systems).
Yes, you are correct there is a problem with longpolling, it tends to consume loads of resources.
What you need is as i can see solution that has a fallback to HTTP longopolling for elder not Websockets API speaking browsers. SSE is a alternvative,but Websockets feels as a more convinent
If you are running on the .NET plattform XSockets.NET can be a alternative, it supports Websockets (RFC6544 and Hybi00) and fallbacks on HTTP Longpolling when needed (i.e IE )
Have a look at http://xsockets.net
Have you reviewed http://signalr.net/ ? Based on websockets but will gracefully downgrade to the nearest available component to support a socket type connection.
Docs can be found here: https://github.com/SignalR/SignalR/wiki
I'm building a web app for 'brainstorming.' Here's how it works: essentially, a user can come onto the app, and submit a challenge, or click on one that's already there, then think up ideas to resolve that challenge and post them up. I hacked together a basic example here on couchdb: http://wamoyo.iriscouch.com/ideageneration/_design/IdeaGeneration/attachments%2findex.html
I'm going to rebuild it from scratch and all, and I'm hitting up against a challenge that's very unfamiliar to me. I'd like for multiple users to be able to generate ideas for the same challenge at the same time. Kinda like the way google docs allows multiple people to edit a shared document. I have some preliminary thoughts on how to go about this, but I thought I'd ask the expert network here.
I'm fairly comfortable with AJAX, is there a pure AJAX way to make it live and multiuser? Would there be an enormous benefit to going with node.js? What might be some other options?
Thanks soo much!
There are several approaches in making such web pages, using plain ajax polling, using long polling and using web sockets.
Ajax polling - easy to implement, essentially connecting to server recurrently via javascript timer, retrieve data from server and send it back via regular Ajax.
Advantages: easy to implement, works everywhere
Disadvantages: the updates are not in real-time, the data is exchanged only when the timer ticks.
Long polling - the idea is that the connection stays open until it times out, then the connection is reestablished. Can be tricky to implement because of different settings for request timeouts for different web servers, routers, etc.
Web sockets - part of HTML5 umbrella, works only in fairly modern browsers, the protocol changes often which may cause incompatibilities during development and production. Can be used natively with modern browsers and via a Flash plugin with older ones. This technology is most lightweight, because it doesn't incur all the HTTP overhead. Think of it as bi-directional, full-duplex communication channel between a browser and a web server via TCP.
For a detailed discussion, I recommend reading this good post by Scott Hanselman. It tells the story about SignalR, but is applicable to other server-side frameworks.
There is also a podcast by same author, the guest goes fairly deeply into explaining these technologies. Worth listening, IMO.
To answer your question about node.js, please share us your current server technology, so we could get more insight into your stack.
I have a couple of questions concerning Web Sockets.
The latest Firefox 4.0 nightlies support Web Sockets. So does Webkit (Chrome 4 + Safari 4/5). Internet Explorer 9 is supposed to feature Web Sockets at some point according to Microsoft (before the stable release).
Anyway, my questions are:
I am building a JavaScript admin interface to manage a website. Should I use Web Sockets for the client-server communication instead of XMLHttpRequest if I told you that I do not need to care about browser compatibility?
Would Web Sockets result in faster save, deletion and update calls compared to the usual situation with XMLHttpRequest? Would the requests be more instant?
I am aware of the HTML5's navigator.online and window.addEventListener('offline', ...), but with Web Sockets (upon connection loss), am I able to detect connection issues more accurately and faster? I mean, when I turn off my Internet connection, or block it with my firewall, Firefox still seems to state that navigator.online is true. With Web Sockets, it seems, the connection to the server will be lost instantly, thus, I can detect connection problems more accurately?
Can I support Web Sockets server-side with pure PHP, so, that the code is portable with other web servers (no need to install any Apache modules or do other customization). I would like to distribute the software to a couple of places without having to ask people to install all sorts of modules to their HTTPD or so.
I wish you can answer to as many of those questions as possible. I am really interested in answers.
I am building a JavaScript admin interface to manage a website. Should I use Web Sockets for the client-server communication instead of XMLHttpRequest if I told you that I do not need to care about browser compatibility?
It appears to me that you want to use WebSockets just for the sake of it. The main reason to use WebSockets is when you want to push data from the server to the client. If your application does not need this, you should probably not use WebSockets.
Would Web Sockets result in faster save, deletion and update calls compared to the usual situation with XMLHttpRequest? Would the requests be more instant?
You could probably save some time on both ends (client and server) due to the absence of headers. But the gain is probably pretty small.
with Web Sockets (upon connection loss), am I able to detect connection issues more accurately and faster?
Yes, an event will fire instantly when the WebSocket closes. Alternatives would be long-polling or periodic XHRs. Or event client-side storage.
Can I support Web Sockets server-side with pure PHP, so, that the code is portable with other web servers
First I suggest you read through this. WebSockets don't work very well in a synchronous way. PHP and apache don't work very well in an asynchronous way. Although there are some implementations, many of them are outdated. I personally would use an other language for this, such as ruby, python, java or server-side javascript. Simply because the languages have better support for the asynchronous model and the WebSocket implementations are more sophisticated.
The WebSocket protocol is currently still a draft, it can change. Just like it did a few weeks ago. So your code may very well break.
My advice is: Do not use WebSockets just for the sake of it. If you have a real-time event-driven application, then it is probably the right choice. Make sure you understand what WebSockets are for and what it takes on the server side, also in terms of event-driven applications. Don't use it for anything production, it's way too fragile.