The Persevere server is an open source JSON application and storage server. Persevere pairs well with Dojo; the Dojo Data paradigm has a strong correlation to Persevere’s data storage structure. Virtually everything you can create or action you can perform with Dojo Data can be persisted in Persevere’s data storage including subobjects, arrays, circular references, and functions. Combining Persevere with Dojo allows you to rapidly develop simple database applications with create, read, update, and delete (CRUD) capabilities with minimal effort.

Comet support in Persevere occurs with HTTP Channels.

You can start building applications almost instantly; no need to create schemas or table definitions ahead of time, simply start creating and building dynamic persistent objects in your data stores, and connect them to widgets for display. You can build your entire application, client and server, in JavaScript.

I was asked to give my definition of Comet in reference to the enough with the connections discussion:

Comet is a collection of techniques, transports, protocols, servers, and clients to deliver low-latency data transit between the server and the client.

The XHR is the least common denominator of Comet, and everything else is an attempt to improve upon the XHR to deliver faster, real-time applications. My definition intentionally avoids some points of the debate, as I prefer to be inclusive and broad, much as Ajax has come to represent everything dynamic in a browser to most people.

I also touch briefly as Bayeux and standards bodies, and JSR-315 for Java Comet servers, and many more general development topics.

Also this week is OSCON where Comet Daily’s Michael Carter and Jacob Rus are speaking about Orbited including a great eight-player real-time game. Check back later this week for more details.

Also at OSCON is the talk Beautiful Concurrency with Erlang by Kevin Scaldeferri. While this talk is not limited to Comet or specifically about erlyComet, it should be a great introduction to concepts that are interesting to the Comet crowd.

Live REST Updates

The easiest and highest level use of HTTP Channels is in conjunction with the JsonRestStore. HttpChannels can be used as an enhancement for the REST service, to enable “live” data (real-time updates that directly alter the data in caches/indexes). To add enable live updates through HTTP Channels messages to the data in JsonRestStore, simply add HttpChannels after loading the JsonRestStore:

dojo.require("dojox.data.JsonRestStore");
dojo.require("dojox.cometd.HttpChannels");

Now, we can create and use a JsonRestStore exactly the same way as you would without HttpChannels:

var myStore = new dojox.data.JsonRestStore({target:"/myTable"});

This is all that is needed on the client side (of course on the server side you need a HTTP Channels capable storage system, like Persevere). All resource/data retrievals made by the JsonRestStore will automatically trigger subscriptions to the resources, and data updates that are sent from the server will automatically trigger the appropriate Dojo Data notifications for updates in widgets.

This means that building an application with Dojo that can load data from a server and receive updates on data changes and update the UI with these changes can be as simple as plugging a JsonRestStore data store into a widget like a grid, and letting Dojo handle all the communication and notification routing. Plugging a “live” data store into a grid can be done like:

<table dojoType="dojox.grid.DataGrid" store="myStore" ...

We can see a very simple example of using a live data store with a grid widget.

Cometd Transport

HTTP Channels is a Bayeux compliant transport, and the HttpChannels module can also be used as a Cometd transport. Simply load HttpChannels after Cometd and it will auto-register itself as a Cometd transport:

dojo.require("dojox.cometd");
dojo.require("dojox.cometd.HttpChannels");
// initialize cometd
dojox.cometd.init("/cometd");
// subscribe to a channel
dojox.cometd.subscribe("/weather/slc", function(){ ... });
// publish to a channel
dojox.cometd.publish("/news/slc", {title:"Hot Weather"});

By loading the HttpChannels module after Cometd, HttpChannels will register itself as an available transport. If the server advertises the ability to handle the “http-channels” transport, the Cometd module will use HTTP Channels for handling subscriptions and publishing messages. It is important to note that HTTP Channels integrates pub-sub messaging with REST resource locators, and therefore publishing messages and subscribing are executing by HTTP requests directly to the target path. With an HTTP Channels compliant server, the example above would result in HEAD request with a subscription header to the relative URL “/weather/slc”, and POST request to the relative URL “/news/slc”.

Standalone Protocol

To use the HttpChannels module standalone, you first get an instance of HttpChannels, the default instance (which is used with the REST services and Cometd by default) can be retrieved:

var httpChannels = dojox.cometd.HttpChannels.defaultInstance;

You can now directly access the HttpChannels API. The primary HttpChannels functions are get, subscribe, unsubscribe, and receive. The subscribe function allows you to subscribe to a resource and provide a callback for notifications. The get function also does a subscribe, but it gets the target resource at the same time as sending a subscription request. The receive function is called whenever data is received from the server. You can use dojo.connect to listen for all messages from the server. For example:

dojo.require("dojox.cometd.HttpChannels");
var httpChannels = dojox.cometd.HttpChannels.defaultInstance;
 
// get the current weather and subscribe to future changes
httpChannels.get("/weather/slc", function(weatherReport){ 
	// this is called for the initial response and all updates
}); 
dojo.connect(httpChannels,"receive",function(message){
	// this is called for all notifications from the server
});

Dojo’s new HttpChannels module provides an efficient implementation of HTTP Channels with strong integration with other modules in Dojo including Cometd and JsonRestStore. HttpChannels can be used for rapidly developing data-centric applications that rely on real-time updates; Dojo provides all the facilities for creating a Comet connection with the server, handling server-sent messages, appropriately updating data, delivering notifications through data stores, and updating widget user interfaces in response to these notifications.

XMPP:

• Put IM on your website
• Manage XMPP components from a browser

IMAP:

• Write Gmail in 20 minutes

IRC:

• Collaborate on Open (and otherwise) Software from a browser

STOMP:

• Message Queue integration — Browsers can be first-class clients in MQ systems

We have already started the above choices with the Orbited project. But there are hundreds of additional protocol choices. What protocols do you want in the browser?

• OSCON (end July, Portland Oregon)
• Rich Web Experience (early September, Washington DC and San Jose, CA)
• Ajax Experience (late September, Boston, MA)
• Web2.0 Expo Europe (late October, Berlin, Germany)
• Javoxx (early December, Antwerp, Belgium)

The new repositories are at

• http://download.dojotoolkit.org/maven2-snapshot/
• http://download.dojotoolkit.org/maven2/

I have blogged at length about the maven incantations needed to use these.

Currently only 1.2-SNAPSHOTs of Dojo and 1.0-SNAPSHOTs of parts of Cometd are published. Releases (including dojo 1.1.1) will be forthcoming once we have some feedback.

Slides

Speaking Notes

Slide: Orbited Logo + Michael Carter

-My name is Michael Carter
- Founder Lead developer of Orbited
- 2 years in development
- countless architectures tested
- now we’ve found the best
- javascript work

Slide: Comet

- Here to tell you about Comet
- Everything I’ve learned in two years of Comet work
- You probably already know what Comet is. But i’ll say it again just in case.

Slide: What is Comet

- Its about asynchronous updates in the browser (Pushing data)
- Not necessarily about a particular technology
- could be flash
- polling
- javascript hacks (streaming)
- Its about an interaction model — user is notified asap with new data
- Its about the applications that you can build with that interaction model
- Chat, clearly
- Financials
- Gaming
- Auctions
- Sports reporting
- Collaborative Editing
- Network monitor reporting / system administration
- Election Monitoring (Andrew Betts / London Paper)
- Air traffic control (no joke)
- To name a few
- In practice though, everyone wants Comet without the need for flash or bad performance of polling
- Just plain old js and html, low latency
- Which brings us to Transports

Slide: Transports
- These are the actual mechanisms for delivering data
- There are many

Slide: Iframe

- Originally we had script tag streaming
- but it made sense to put it in an iframe
- So we refer to it now as iframe streaming

Slide: Iframe Diagram

- Application page has a callback “receive”
- Finishes loading, creates and iframe
- Iframe causes an HTTP request to the server
- the server sends headers
- (transfer-encoding chunked for http 1.1)
- And then stops
- The key to this transport is incremental rendering
- Browser will try to display any open/close tag pair that it receives
- This includes displaying invisible elements, like script tags
- So the server can cause the browser to execute arbitrary javascript
-

Slide: Iframe Code
- Easy to implement
- Works in all browsers with the same code
- Suffers from..

Slide: Iframe Usability
- Loading Bars
- Hour glasses
- clicking noises?!

Slide: Iframe Unacceptable
- Modern applications can’t have clicking noises and hour glasses.
- The users would get too confused
- So Iframe streaming isn’t the most popular transport
- Instead, the most popular transport is…

Slide: XHR Long polling

- Long polling is what the cool kids do.
- (Meebo and Facebook, for instance)

Slide: XHR diagram

- Browser says, ‘Give me an event’
- Server says, ‘…’
- Server says, ‘event.’
- Browser says, ‘Give me an event’
- server says ‘…’
- Its cross-browser

Slide: Long polling code
- still easy to implement
- and no usability issues!
- seems like a big win
- but how does long polling performance compare to iframe streaming?
- Consider an island off the coast
- its surrounded by water

Slide: Island
- We want to send conveys to the island, so we build a bridge

Slide: Bridge
- Conveys can now go to the island as they please
- But maybe a big ugly bridge is not what we wanted… its too unsightly
- So instead we build a boat

Slide: A boat
- The convey arrives at the boat, and the boat takes it to the island
- no problem
- But what about the second convey that arrived just after the boat leaves?
- It waits for the boat to go to the island
- It waits for the boat to come back
- It gets on, and waits for the boat to go to the island
- 3x travel duration
- Well Iframe streaming is the bridge, and the boat is long polling
- Meaning, long polling suffers from a 3x latency performance hit
- But thats not all
Slide: Bandwidth comparison
- You also have to send headers all the time
- Your buddy says ‘hows it hanging’
- But the browser says ‘GET /some/url HTTP/1.1\r\nUser-Agent: …etc’
- And the server says ‘HTTP/1.1 200 ok\r\nContent-type….’
- your 15 byte message can easily incur 300 bytes of headers, or more!
- thats a 20x bandwidth increase in that case

Slide: Long polling unacceptable
- 3x latency is too much
- 20x bandwidth is too much

Slide: Strike 2, you’re out
- Strike 2, you’re out
- or so we thought

Slide: Htmlfile Object
- htmlfile object to the rescue

Slide: ActiveX!
- but safe for scripting
- hides usability issues

Slide: Garbage crossout
- leaks live connections on navigations
- But we can fix that by explicitly calling the garbage collector

Slide: Htmlfile works great
- Streaming
- But No side effects
Slide: Explorer only
- partial solution
Slide: Xhr Streaming
- transport for ff and safari
Slide: ready state 3
- don’t do one event per request/response cycle
- do a hundred. a thousand…
- ready state 3 saves the day
- callbacks for download progress from server
- responseText is just plain text without any inherent meaning

Slide: Manually parse
- So invent our own format
- parse it manually
- And we’re set for firefox and safari
- Without loading bars or anything
- and the same bandwidth and latency constraints of iframe streaming
- So we’ve got all the browsers
- Except opera

Slide: SSE

- Opera goes above and beyond the call of duty
- I don’t ask that browser’s make my life easy
- They can keep their nasty forest of terrible hacks
- All I ever asked from browsers is that they make it possible to do comet
- But Opera actually makes comet a first class citizen of the browser
- Create an event source, name a url, add a listener. The end.

Slide: Html5

- Then they went on to propose that the this be included in HTML5
- after discussions with other vendors, gained support, a new spec came up

Slide: deprecated

- so the new one isn’t implemented
- but thats okay
- we can use the deprecated one in opera 8+

Slide: Transport Conclusions 10.18.20
- Ten minutes to explain
- Years to discover

Slide: hacks
- And yes, its hacks, hacks hacks

Slide: aim carefully
- Developing these transports is like trying to throw darts at a board

Slide: moving target
- but the board moves after you’ve thrown the dart
- That is to say, just imagine the most frustrating game you can
- That game is twice as fun as building transports

Slide: sleek bridge
- We can avoid the boat transport (long polling)
- And provide great user experience
- get a nice looking bridge

Slide: sleek bridge image with orbited logo superimosed
- And orbited does just that

Slide: Scalability
- Once you have a way to do comet, you need to scale it
- where transports are frustrating, scaling is hard
- Step 1,

Slide: Vertical Scalability
- How do you put lots of users on one machine?
- Seems like such a hard problem, but really there’s a simple trick
- And once you know the trick, its possible
- Don’t use threads.
- People have tried this with servers like apache
- A reasonable thread count, of 20, will service 20 users
- A better user count is a 1000 though
- But a 1000 threads brings a system to its knees with context switches
- No comet, just thrashing

Slide: Comet + threads != scalable
- So use the little trick of omitting threads, and you’re golden
- Build event-based servers
- You don’t want your comet apps to be like nature preserves
- You don’t want your app to be a lonely desert with the occasional wanderer
- it should be a riot, with users tearing down the walls, sucking your resources dry, demanding more…

Slide: desert -> riot
- So use event based programming for your comet server
- And I guarantee, your app will be a riot, not a desert.

Slide: zzzz
This is the easy problem
The harder problem is the other “half” of scaling,

Slide: Horizontal Scalability
- If one server supports 1000 users, does 2 support 2000? and n, n-1000?
- This is a truly tough problem
- Really though, it depends on the application
- No one answer.
- But a few core rules are in order
- 1. Don’t share state between comet servers
- 2. Only do Comet in the Comet server. no Pub/sub, no jabber/game server, no load balancing, just comet
- 3. Treat comet as the last leg of the journey

Slide: Two Comet servers (sharded by user) doing pub sub (ajaxworld slide)
- For some reason, comet servers are all trying to provide a pub/sub api
- Developers like it, great.
- But it was already a hard problem before Browser’s existed
- And the people solving the problem, RabbitMQ/ActiveMQ, aren’t part of the comet community. (there have been minor inroads)
- Integrating streaming comet sith real publish/subscribe message queues would be great
- But, thats just a specific case of a larger issue
- The real issue with scaling comet applications is that
- Comet is difficult
- Comet imposes architectural constraints on web apploications that we aren’t used to (can’t do round robin balancing per http request)
- Its a moving part that has to be closely tied to the other pieces of the system
- But integrating comet with existing technologies would allow us to solve the horizontal scaling problem however these existing technologies already solve it.
- How could you scale a thick client deployment?
- We want that to be the only question to answer when scaling a comet application.
- So How do you integrate comet servers with X?

Slide: Offboard Comet integrated with Jabber
- This is an example of how a typical comet server is integrated with jabber.
- the browser maintains a connection with the comet server and the “bridge”
- The bridge is an http server (hopefully event based as well!)
- and also an xmpp client
- and also a “Comet client” (dispatch protocol)
- Message flow goes browser -> bridge -> jabber -> bridge -> comet -> browser

Slide: A lolcat tangled up
- This is a bit of a mess
- complex systems are hard to scale

Slide: previous slide (Offbard comet integrated with jabber)
- you can’t scale this with your typical web load balancer
- the mapping between comet servers, bridges, and xmpp servers are almost certainly not giong to be 1-1
- so you have the complex task of figuring out load balancing between each part
- and then you have to implement each client twice
- once for the bridge, once for the browser
- the bridge speaks xmpp to the jabber server, but json-chat (made up protocol) to the browser
- Clearly not the solution…

Slide: Victory march picture, maybe the planting of the american flag in some battle
- Standards save the day.
- HTML5 has specified a TCPConnection standard for the browser

Slide: TCPConnection (word)
- I’ve been working closely with whatwg/w3c to specify the protocol and api that solves all of our problems
- tcpconnection is just like a socket, but for javsacript in browsers
- It will
-traverse forward proxies
- speak ssl
- include cookies (auth integration)
- use a single socket for both directions
- revolutionize web applications
- Think about it — tcp connections revolutionized network programming in the 70s.
Slide: Iron Man screenshot during test sequence
- tcp/ip. Thats how dad did it, thats how america does it, and its worked out pretty well so far
- And we don’t even have to wait for browser vendors

Slide: The future is now (sci-fi-ish picture + words?)
- Orbited provides a TCPConnection to all major browsers, today.

Slide: Browser < - > Comet Proxy < - > Jabber diagram
- Orbited speaks comet transports on the front
- and plain old tcp on the back
- So you put it in front of ANY tcp server
- and the browsers can interact as if they’d connected directly to the backend server over tcp.
- and the server doesn’t need to be altered whatsoever.
- No need for a bridge or dispatch protocol
- Much less complex means easier to scale
- Load Balancing?
- We can simplify this picture still

Slide: Browser < - > ( comet Proxy + Jabber Diagram single machine)
- Treat the comet proxy as part of the server
- One comet proxy per backend server
- Now you can all sigh in relief

Slide: Sigh of relief
- Because Comet isn’t going to get in the way
- Scaling Comet applications horizontally isn’t a twofold problem anymore
- If you know how to scale a network application, then you can scale a comet application.

Slide: Jabber server cloud with half Comet proxies, half normal
- And whats more, there’s no difference between the browser and the desktop

Slide: Auth + persistence (a pair of keys and some kind of storage)
- There are a couple of details: authentication and persistence

Slide: Jabber server with comet proxy on left, web app on the right, sql server behind both
- Just have the network server and the web app coordinate on the back end
- put the sql server behind both
- User creates an account over the web app
- but can log in to jabber
- jabber saves logs to the database
- and the user can see those logs via the web app
- And your problems are over.

Slide:Conclusion (Bullseye (with orbited logo somewhere))
- Transports are frustrating, but Orbited implements them (indeed, a number of projects take our implementation directly)
- Vertical Scalability and threads don’t mix. Orbited use event-based network IO.
- Horizontal scalability is tough because you have two problems.
- If you can solve integration, then you can get a handle on horizontal scalability by normal means
- TCPConnection is the perfect integration point. It works with all past, present, and future tcp/ip servers. Out of the box.
- Orbited provides that functionality today.

Why Comet

The Open Anzo project uses Comet to provide a unique programming model for data stored on a server. With Open Anzo, you can replicate chunks of data from a server to work with the data locally. Those replicas are automatically kept up-to-date via Comet messages sent whenever the data changes. This model lets the developer focus on working with the data rather than focusing on the requests and mechanisms for retrieving the data. Since Open Anzo implements this model using a message broker, we are able to extend the model to the web by building a Bayeux to JMS bridge.

Nuts & Bolts

With a thin JavaScript object wrapper around Cometd and a small server side component, we are able to expose most of the basic JMS functionality to the browser. While we don’t expose every nuance of the JMS API, we can communicate with a JMS cloud as a full participant even from a browser. For our implementation we use ActiveMQ as the message broker, which has its own Comet bridge. We chose to build our own bridge using Cometd Bayeux for its various advantages such as pluggable Comet transports and resiliency across transient network failures. Also, we need it to work with any other JMS message broker.

The core of the bridge implementation is the BayeuxJMSBridge server-side component. Its sits on a Jetty server instance and listens for Bayeux messages from clients and forwards the messages via JMS on behalf of the client. It also receives messages from the JMS cloud and then forwards them onto the interested clients as a Bayeux message. Browser clients use the JMSClient object to subscribe to JMS topics or to send messages to queues. For example:

// Subscribe to a JMS topic
anzo.messaging.JMSClient.subscribeToTopics("interestingTopic",
function(msg) {
    // msg.properties contains the JMS message properties
    // msg.body contains the JMS message body
    // ...
});
 
// Send a request and expect a response.
anzo.messaging.JMSClient.publish({ properties: {}, body: "my request"},
"myDestination", function(msg) {
    // Work with response message...
}}}

Notice that the ‘publish’ method supports request/response style interactions. Internally, the JMSClient object will add a randomly generated “correlation id” to the message and save the given callback function mapped to that id. Then, whenever a message arrives on a Bayeux channel on the client, we check if it contains a correlation id. If so, we look up the corresponding callback and invoke it with the newly arrived response message. This is all transparent to the client. It simply knows that it has sent a message and its callback is eventually called with the appropriate response message. The difference between a PubSub message and a request/response message is simply that a request/response message contains a correlation id.

Whenever a browser client connects to the bridge, a new JMS temporary topic is created on behalf of that client. That is where messages bound only for that specific user will be sent. Each such topic is mapped to a Bayeux channel for the specific user (ex. “/anzo/user/myUser/34xWtez-i”). To make sure that only the intended client can subscribe to that client-specific Bayeux channel we plug in an implementation of ‘dojox.cometd.SecurityPolicy’.

Future Enhancements

For private request/response messages we create a Bayeux channel per user. We might consider a less resource intensive approach as Greg Wilkins describes. Also, JMS message brokers provide various quality of service guarantees but, with our implementation, those guarantees aren’t preserved between the browser and the bridge. We will explore some of the many methods to add service guarantees to Comet.

Conclusion

With Comet, Open Anzo is able to provide a powerful model for manipulating data on the web. Having small local replicas of data automatically kept up-to-date lets developers focus on rendering and using the data rather than building APIs to get at it. And by tapping into JMS-based infrastructure we make the browser a full participant in an asynchronous message passing architecture.

Rupy takes an interesting approach with a very very tiny Java server implementation. Even if Java is not your server-side language of choice, it’s worth taking a look:

Weighing less than 50KB, rupy is probably the smallest Java NIO HTTP server in the world.

Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data.

Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn’t use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency.

In the succinct words of Rupy project lead Marc Larue that help define what Comet is really all about:

As for a starting point I think that there is a bigger picture to the new-wave of web techniques that fueled rupy’s creation.

Comet and REST both have simplicity as the common energy source, after all HTTP is just TCP and web-services being over-engineered is an understatement.