Building the Realtime User Experience 102
rheotaxis writes "Many professional web developers have spent years building dynamic, database-driven web applications, but some of us, like myself, want to make the user experience more interactive and instantaneous. The book Building the Realtime User Experience, by Ted Roden, is an introduction to some new techniques making that happen now. New web servers like Cometd and Tornado power solutions that keep HTTP connections open until data is available for the clients requesting it, a technique called 'long-polling.' This means web developers can provide a real-time user experience using HTTP for all sorts of client devices now connecting to the Internet, not just web browsers, but mobile devices as well." Read below for the rest of rheotaxis's review.
This book covers SUP and PubSubHubbub syndication, messaging with Bayeux protocol and Cometd, and asynchronous Python using Tornado, contrasting these with well-known client-side JavaScript methods. It then demonstrates how long-polling can implement and integrate chat, IM, SMS, and analytics. The last chapter wraps up with an example using all these technologies, a multi-user, real-time, interactive game using geo-location with mobile clients. Ted's writing style is concise and to the point, focused exclusively on the challenges presented and solved in each chapter, including just enough details for experienced programmers to download and setup the software tools being used, including the Google App Engine. The code samples are straight-forward, but be forewarned, it will be easier for readers with some experience building server-side scripts like PHP, Python, or Java, and a database server like MySQL. On the other hand, even if you never used Google App Engine before, that's OK, because Ted covers that in enough detail to get you started quickly. The sample code wasn't yet available on the O'Reilly web site, so you'll need to type in the code samples to try them. Check the O'Reilly errata page for the book to get a head start making the code work. (Full disclosure: I posted some of the errata.) The sample code for Cometd and Tornado ran easily on my laptop (HP 2.2 GHz with Windows Vista), and should be fine on Linux or Mac. Everything you need is open-source and easily downloaded.
| Building the Realtime User Experience | |
| author | Ted Roden |
| pages | 320 |
| publisher | O'Reilly Media |
| rating | 8/10 |
| reviewer | rheotaxis |
| ISBN | 0596806159 |
| summary | Shows you how to build realtime user experiences by adding features on your site without making big changes to the existing infrastructure |
The author explains that real-time web development puts the user at the center of all web interactions, and that developers have struggled with solving the push versus pull problem. The pull method requires multiple, periodic queries for updates from server information feeds, something that wastes server CPU and bandwidth when no changes have occurred, and is compounded by the number of different users making these queries. The push method allows the servers to contact the clients when information feeds have been updated, saving CPU and bandwidth.
RSS was designed for easy syndication of information feeds, but it suffers from the limitations of the pull methodology. While several push technologies have been proposed to solve this problem, only Simple Update Protocol (SUP) and PubSubHubbub are covered in detail here. Both of these are demonstrated with PHP code, so they should be easy to implement on hosted web account with PHP and MySQL. The author explains that while SUP isn't a real push methodology, it does address some the CPU and bandwidth issues. PubSubHubbub, a true push methodology when compared to SUP, is described with an equal amount of detail.
Next, the book covers techniques already familiar to JavaScript programmers who have experience building AJAX enabled web pages. Skim the text and glance at the code and diagrams in Chapter 3, if you already have this experience. The subtitle for this chapter is "Widgets in Pseudorealtime", and the key take away from this chapter is that client-side JavaScript can be used with pull or push technologies, depending upon the server-side implementation. If you don't yet have experience with AJAX, then be sure you can follow these code examples, because AJAX will be used in all the other chapters.
Have you ever wished your blog could send live updates to your readers the moment you post them? You'll learn how, using Bayeux protocol, Java, Cometd, and the Jetty web server. The sample code allows you to grasp how long-polling works with modern browsers. Once a client browser opens an HTTP connection to a web server using a POST method, the server leaves this connection open until it has data to deliver to the client. This chapter suggests using Firebug, a Firefox plugin for debugging web applications from the client side, to discover and track long-polling seasons.
Do you need to handle a large amount of incoming data, and then redisplay it on client browsers with almost no delay? Tornado, the Python web server, provides a solution. Tornado was created by FriendFeed, and made open source after being acquired by Facebook. Kudos to Facebook for making Tornado available. Please read Chapter 5 and 6 together, since they both explain how the Tornado server works. The sample code starts with Python threads that cache a Twitter feed, process and filter it, then send it out to web browsers already connected to Tornado using long-polling and asynchronous callbacks. Tornado is then used to implement a peer to peer chat system using long-polling. Again, each client stays connected to the Tornado server until messages are ready to deliver to each chat participant. Taken together, Chapter 5 and 6 lay the groundwork for more advanced Tornado web applications covered later in the book.
This is followed by two chapters using the Google App Engine to support real-time user experiences even though the Google App Engine does not support long-polling. If you have never used Google App Engine before this, don't worry. The author spends 10 pages explaining how to sign up. Then you build an application in the cloud and connect with your IM client, instead of the web browser. You can make your IM server accept commands and respond with information from other web services. The section, "Setting Up an API", gives you a tantalizing glimpse of possibilities explored later in the book. After adding Python code from the next chapter, you have SMS capabilities. Why would you want to do this? Because it allows users to keep informed while they're away from the web, making SMS another part of the real-time user experience.
Once you have implemented and deployed your real-time application, you can add analytics that give you immediate feedback about user interactions with your site. Instead of paying for a service, you can build your own custom web analytics using Tornado and client-side JavaScript. I especially like the authors approach to summarizing all the incoming web usage data into a single, super-simple, HTML template that is immediately updated as web usage changes. It should satisfy your curiosity to watch users interact with your web site in real-time, and you can make it track IM and SMS traffic connecting to your server too. Finally, the last chapter demonstrates how all the know-how you learn from the rest of the book can be combined in new and highly imaginative ways. The author provides all the details you need to setup a location-based, multi-user, real-time, interactive, game played by users with mobile web devices.
This book would be good for anyone that needs to quickly learn how to use Tornado and integrate it with other web services. It's also helpful for people who want to integrate the Google App Engine with other web services. Whether you're going to build a real-time web experience from the ground up, or just add a few more dynamic features to an existing site, the lessons you can learn from this book will help you.
You can purchase Building the Realtime User Experience from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I didn't read the whole thing (Score:5, Interesting)
Look, I'm going to be honest here, I didn't read the whole summary; it's long. But I did read the main part of it, at the beginning, and what it's suggesting is keeping open an HTTP connection so "real-time polling" (which is sort of an oxymoron to begin with) can occur.
I don't know how others feel about this, but to me it feels like.. putting two things together that don't belong. HTTP was never really designed for this sort of thing. Why don't they use straight sockets and TCP/IP? Why does it have to be HTTP?
Re:Is socket connection latency all that relevant? (Score:5, Interesting)
Having worked at a large firm that is one of the local market leaders in social networking, I can tell you that polling your system every 5 or 10 seconds can cost you a lot of money in hardware and bandwidth.
Even an empty HTTP request is about 1kB with all the overheads (browsers sending cookies, etc). If you've got 1M visits daily, each spending 60 mins on your site, that easily gets you in the bandwagon of 720GB of traffic *daily*.
This is in addition to all the server workload - the best server can roughly deliver 1000 requests/s. Your 500k of peak simultaneous users would then require 50 servers just to handle their idling.
At the same time, a long pooled connection can stay open at least 3 minutes, and often enough well over a day, sending small (60byte) keep-alive packets every few minutes.
This is much, much cheaper.
Re:I didn't read the whole thing (Score:1, Interesting)
At least in browser based Java, for security reasons, a socket can only be opened back to the same host as the page was loaded from (a good idea).
Due to firewalls, especially corporate firewalls, the connection needs to go out on port 80.
Combine port 80 with the originating host, and you are stuck with the web server accepting the new connection and expecting it to be HTTP.
Due to proxys (again especially corporate), and some firewalls it is a good idea if the port 80 traffic looks like HTTP.
To cover the largest user base you either stick with AJAX or use on of the tricks like the book describes to keep the HTTP socket open for a long time.
Back in the very late 90's I worked for a company that pushed financial quotes out to a java applet in the browser. The web server used an ISAPI extention that could "steal" the open socket from IIS and leave it under control of a DLL that continued to send quotes. A lot of moving parts, but it got the job done at the time...
Re:Is socket connection latency all that relevant? (Score:2, Interesting)
Well, the trick is having them open for longer than the frequency of querying the server. Most server software (unless you use a very inefficient code/server) tend to be CPU and not memory-bound (noteworthy exception - cheap virtual machines).
Besides, creating a connection is more costly than actually maintaining it for longer, even if done at the same frequency. You might run out of file descriptors, you might want to mitigate it, besides that, a single open stalled connection is maybe 4-32kB of RAM, depends on the chosen platform, if a single thread can handle multiple connections.
This is the magic cometd does - it basically herds these connections.
Re:I didn't read the whole thing (Score:2, Interesting)
Well said. That's exactly what I'm trying to do with this book (I wrote it). This is a very practical book in that you should be able to start implementing these technologies at scale in any modern browser and working with your apps existing ecosystem.
While I would have loved to put in a chapter on web sockets, It wasn't practical in terms of time or practicality. However, the 2nd edition (fingers crossed) will definitely cover it.
-Ted
But apache isn't at fault. (Score:4, Interesting)
It is the protocol itself. HTTransferP and TransmissionCP is designed to transport data - not sit around and wait for it. Yes, tornado is better at handling multiple connections than apache - but it will still result in poor server performance when you have tens or hundreds of thousands of socket descriptors sitting in swapped-out virtual memory.
If you want to build a real-time, instant notification application, you need to forget HTTP and use a protocol suited to the requirement. The best solution I can think of right now is the SUBSCRIBE/NOTIFY model that was designed for SIP. The next best choice would be a straightforward application of SMTP. Both of these deliver data on-demand. Both have been around for several years. Both of them will scale into the millions without using a relay or a masquerade.
Popularity != Good design
Re:I didn't read the whole thing (Score:3, Interesting)
``HTTP was never really designed for this sort of thing.''
Exactly. The World Wide Web is good at what it was designed for: static pages with text and hyperlinks. Go to your favorite search engine, type in some keywords to describe what you're looking for, and it will find you pages with information about that. The Web does this better than any other system I know of.
If you want to build interactive, responsive, graphical applications, HTML and HTTP aren't the right tools for the job. This isn't what they were designed for, and they aren't very good at it, either. Add CSS and JavaScript and you can get a long way - provided the user has a browser that handles what you feed it the way you want it, and the user has a PC that is sufficiently overpowered for the task at hand that it will run smoothly, even though it is programmed very inefficiently. HTML 5 intends to give people who want to go this route some more tools to work with, like the canvas element. However, this is just piling on kludges and throwing CPU cycles at it until it kind of sort of works well enough. Still, the success of, for example, Facebook, shows that there is demand for applications that go beyond what HTML and HTTP were made for.
What I have been advocating for years is creating an open technology that really lets people do the things they want to do that are beyond the scope of HTML and HTTP. Pixel-perfect graphics, lightweight two-way network communication, a complete set of GUI widgets, and a runtime to allow safe and efficient remote code execution, complete with a library system to allow for extensions to be written and distributed efficiently and without stepping on each other's toes. Since neither web standards organizations, nor web browser makers have shown eagerness to work in this direction, I have decided to do it myself. I have just recently begun to write down some ideas, under the name Jungle [inglorion.net]. It does everything I just mentioned, and while I'm at it, I want to throw in 3D graphics and a generic data encoding [inglorion.net] designed for efficiency and to be easy to parse (because, frankly, HTML is a mess, and XML, while popular, wasn't the best choice at the time it was invented, and certainly isn't a good choice for some of the things it's used for today).
As I said, I have only just started to write these things down, so these aren't complete specifications yet, and there certainly isn't a working implementation yet. I'm trying to get more time to work on this, but if anyone wants to help, that would be greatly appreciated. My plan was to get a more complete picture online before drawing people's attention to it, but this story seems like a good opportunity to get people's attention, so here goes. If you like what you see, I will be delighted. And if you have a better idea, let's hear it! I will be looking for help getting implementations written once the specifications are up, but that is going to take a while. If you would like to help, though, drop me a line [inglorion.net] and I'll keep you in mind.