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.
Related
I put together an AJAX chat a while back ASP.NET MVC and jQuery. The javascript would hit the server about every 7 seconds to check for new messages. Obviously this was horrible on performance as the chat grew and included more and more users. The site traffic grew exponentially with so many requests going on. A user could leave the computer on all day and not even be there and they would still be making hits every 7 seconds.
Is there a better way to do this? I have heard of something called "push" but I haven't really been able to wrap my head around it. I think I just need pointed in the right direction.
1.) What is the best way to develop an AJAX chat and have it be scalable?
2.) What is push and how would I just that with jQuery?
1.) What is the best way to develop an AJAX chat and have it be scalable?
I agree with #freakish about the complexity and potential lack of scaling of IIS.
However, there is a relatively new Microsoft option in the works called SignalR which could become a core part of ASP.NET. More details in this related SO Question:
AJAX Comet - Is there any solution Microsoft is working on or supports to allow it to be scalable?
2.) What is push and how would I just that with jQuery?
Partially answered elsewhere, but it's a long-held persistent connection between the server and the client which means the server can instantly 'push' data to the client when it has new data available.
jQuery does support making AJAX requests but the core library doesn't support expose ways of doing HTTP Long-Polling or HTTP Streaming. More information in this SO answer to 'Long Polling/HTTP Streaming General Questions'.
Server push is a technology that allows the server to push data back to the client without forcing client to make many requests (like every 7 seconds). It is not really a matter of javascript but rather good server scripting. The upcoming HTML5 will make it simple due to server-sent events and/or WebSockets. This will be a true TCP connection between different machines.
But if you intend to make a webpage compatible with older browsers, then the most common technique is the long polling. The client sends request to the server and the server does not respond to it until it has new data. If it does then the response is made and the client immediatly after receiving data calls the server with new request. In practice however this requires the server to be well-written (for example it has to maintain thousands of idle requests at the same time) and can become a rather big challenge for developers.
I hope this helps. :) Good luck!
The technique you should use is the real-time persistent long running connections over a web page using WebSockets. You can use this library.
Node.js is becoming quite popular to build something like this and supports socket connections so you could push the data out only when there is a new message. But that would be learning something completely new.
Another nice potential would be to use MVC's OutputCacheAttribute and use the SQL dependency option so your AJAX page could be cached and would only be a new request when a new chat message appears. Also you would want your controller to be an Asynchronous controller to help reduce the load on IIS.
Enjoy, optimization is always fun and very time consuming!
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.
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
The common way, I think, is making a periodic "ping" to the server, but I don't like how it looks too much like
"Is there anything new? - No"
"Is there anything new? - No"
"Is there anything new? - No"
"Is there anything new? - No"
"Is there anyt..."
I've seen another approach where client ask for news and server "retains" the request (with a sleep loop, for example) until there is anything new. That's cool, but I'd really like to hear about another options.
Unfortunately there isn't really any cross browser mechanism for pushing data from the server to the browser. For example, back in 1995 Netscape released a server push technology that uses a special content type -- multipart/x-mixed-replace but from what I understand IE doesn't support it. WebSockets are a new one but support is just coming out now.
So you're forced to use the tools at hand, which means the client needs to ask the server if there's any new data -- polling. Polling comes in 2 varieties: polling on an interval, and long polling. When you poll on an interval you simply make a request to the server every n seconds asking for data. This is fairly chatty (pardon the pun) if there is no new data to return. This is what people think of when you say "polling."
The other option, long polling, is similar in that the client makes a request to the server to see if there's new data. But in this case the server doesn't send a response until it has something to say. In this case the client is left hanging for a response for an undetermined amount of time. When the client eventually gets its response it parses the response and immediately makes another request which will stay hanging until there's data.
Both of these polling approaches consume a lot of HTTP overhead, but if you want to use XHRs this is about the only way to do it.
A word of warning about long polling: When working with long polling it's important to ensure that all of your XHRs are running asynchronously otherwise you'll see the browser's UI thread lock up.
If you're not interested in using AJAX then you can always use the tried and testing IFRAME-that-never-finishes-loading. In this case you have an IFRAME with the chat log and another IFRAME that contains your message area. In this case the server simply never closes the connection for the IFRAME that contains the chat log. Instead, it just keeps pushing chat messages into the body.
WebSockets can be helpful if you're okay if some browsers aren't able to use it.
If you want to it in JavaScript, there is no alternative to polling in intervals.
What you need is ajax push or reverse ajax.
There are lots of ajax based frameworks who support push. In Java for example nextapp echo2, or you can give a shot to ape project as well.
Options
Long-Polling: keep the request open until data arrives. Receive data and close connection. Open a new connection to receive data again. For this to scale you need to have non-blocking IO)for all communication). This approach is the simplest to implement. You could even use blocking I/O if your server does not have a lot of concurrency.
HTTP-Streaming: Do not close the connection when receiving data. For this to work cross-browser you have to do some "hacking" to make it work in all browsers.
XMPP over BOSH For this you use your XMPP server and sprinkle it with some BOSH(XMPP over HTTP). Prosody for example is an easy XMPP server which supports BOSH. Next you could write the client-side with the excellent strophe.js library.
Websockets: I guess this will be the future, but right now the browser support is not sufficient to really use it for all browsers.
Server-Sent Events: Also pretty cool html5 feature. This protocol is in my opinion simpler then websockets. This also is not widely supported by all the majar browsers yet.
Flash: You could also communicate via flash if you like. The browser has to have flash plugin installed, but that will be the case most of the times.
What is the best way?
In my opinion long-polling is the easiest/best way to implement event-based messaging over HTTP. it definitely is not the fastest alternative, but every major browser supports it and the easiest to implement.
I think Websockets will be the best technology(future), but is not widely adopted in the browsers yet.
All though all the above technologies are pretty good. They all have there pros and cons.
If this is done with JavaScript, there really isn't any other way than pinging the server. You're only option is to heavily optimize the request, to avoid uselessly asking the "question".
I have to program websites, but I rather don't like the static HTML nature. I prefer more of a client-server architecture.
Now I've figured, that with XMLhttp, you can basically dynamically update your page and send/request for information/action to/from a server. So this would basically cover the client area.
But to complete a client-server architecture, it is necessary for the server to send/request information, too, without being queried.
Is there any way, for example for a chat server, to send back a received message to all clients (the clients use a web browser) without that the clients have to query in a fixed interval? I want to implement that one can see while you type something in.
There are several different ways to accomplish this. Some of them are already answered here, but I wanted to include a few more as well as my thoughts on them.
1. Polling
Frequent requests are made to the server to check for new info. This is the worst way to do this, but probably the easiest. If your site will have a low number of users, it might be worth doing it this way.
This can be accomplished by using setInterval(myFunction, n) in javascript to send XMLHttpRequests to the server every n milliseconds. Then, on the server, you respond to this with your new info, when you have it, or some message that implies no new info.
2. Long Polling
When the page is loaded, it makes a request to the server for new info. The server holds the connection open until there is something to send back. This method reduces the amount of network traffic used, but increases the resources used on the server. You can use this for a small number of users, but it doesn't scale very well.
The easiest way to do this is to have the page that handles the AJAX request simply wait for new information to be available, then respond. This can tie up a lot connections on your server. So, use with care.
3. COMET
COMET is basically long polling, but the server is setup properly for it. It knows that these connections aren't "real" and it uses less resources to handle them. This is a great solution for this problem, but it requires that the server is explicitly setup for this purpose. There are COMET servers and COMET addins for other popular servers, but it will require some setup and sometimes some money.
Implementing this on .NET isn't the easiest thing in the world. You can pay for solutions, try to find someone else's code that does something similar, or try to write it yourself. I've not found any decent free solutions for this. If someone else has, please comment.
4. RIA
Another solution would be to include Flash, Silverlight, or Java Applet on your page. People often do this by using a 1x1 object so that they can use Flash or Silverlight to talk to the server. If you don't mind adding the dependency, this is a decent solution. If you already know Silverlight or Flash, it could be relatively simple to implement.
You can find tutorials on the internet for each of these options.
5. Web Sockets
If you are on the cutting edge, you can look into Web Sockets. It's only available in the latest builds of modern browsers. It was part of HTML5, but it might be its own spec now. Regardless, it means that older browsers won't be able to handle it. But, if you don't mind limiting yourself to the latest of browsers, you can use this amazing feature.
I believe that Chromium is the only browser that currently supports it. However, there is work being done to implement this in Firefox and WebKit.
I'll spare you the controversy and simply say that this does exactly what you want it to. The Abstract of the spec says it all.
This specification defines an API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
Special Mention
If you are interested in the world of Node JS, you can't go wrong with Socket IO. It will implement the best of whichever technology is available to the browser.
Conclusion
The best option is Socket.IO on Node JS. However, for an ASP.Net solution, go for COMET or Web Sockets, if you can. Otherwise, using Flash/Silverlight isn't terrible. Finally, polling and long polling should be last resorts. You could always support one of these, then fall back to another if there isn't support for it in the client's browser.
Yes, you can use COMET.
The client has to tell the server when the client-user begins typing. You've got a couple options here.
Frequent requests from the server for the latest activity. This would be taking place for each user involved in the chat. The same request could be used to send user-specific activity to the server as well: "Jonathan is typing..."
Long-polling. This essentially requests information from the server, and the server keeps the connection opened until it has something to send back. So your requests are minimized, but your connections stay opened longer.
Depending on your traffic, type of data being transmitted, server-environment, and many other factors, one of these options may shine more than the other.
You can use Silverlight for push notifications. Look at PollingDuplexHttpBinding. Since you are using ASP.Net MVC, adding Silverlight will be easy.
Look at this page for more information.
Based upon the REST architecture the html system is based upon, the servers role is to simply act as a resource for the client to pull from. I am generalizing but there are tools to implement this type of action on the client side, rather than on the server side.
You are better off writing/using a library that can request updates from the server periodically. You can encapsulate these types of requests in a javascript object that can fire events. This way your client side script can act like it's getting notified from the server. Review some common stuff with COMET you can probably find some tools to help you client side code.
HTML 5 has some tentative attempts at this type of functionality, but if you want your app to work on older browsers, your better off using more stable methods, like AJAX requested updates.