Saikat Chakrabarti of Mockingbird is looking to make the tool collaborative. Along the way he wanted to test out tools to make this happen, and one test ended up with a collaborative drawing program using Node.js with WebSocket support from Socket.IO:

, the actual interesting parts that are doing anything other than serving static files start with the line “var listener = io.listen…”. On the client-side, I made a very simple Objective-J class that wraps the Socket.IO client called SCSocket (located in client/SCSocket.j). It’s up to you to simply set a delegate on this class and implement any of four methods (see setDelegate: on SCSocket) to handle notifications from the backend. To send notifications to the Node server, simple call [[SCSocket sharedSocket] sendMessage:].

Check out the code on GitHub.

On the client side:

And the backend....

Nice!

Chrome and Firefox will soon be supporting WebSocket, so WebSocket (for better or for worse) will soon be available in the wild.

So if you can’t beat them, join them. Having failed to convince others to create a better protocol, I’m now determined for Jetty to provide the best implementation of the protocol and to become the server of choice for WebSocket Comet development, deployment ( and experimenting with improving the protocol).

Jetty’s async IO architecture is ideally suited to providing a very scalable implementation of WebSocket that is well integrated with standard server-side java application environments. Thus Jetty-7.0.1 now includes a WebSocket server.

Following their recent acquisition by Google, AppJet announced they would open source EtherPad, the collaborative, real-time, notepad. That's now done, and you can find the project home at - surprise, surprise - Google Code.

Checkout Instructions

Browse the Source

What's especially cool about this is that Etherpad is Javascript on both sides of the wire. In a new ReadWriteWeb article on Server-Side Javascript, I wrote that EtherPad is probably the most popular site powered by Javascript (anyone want to up the ante?). As server-side Javascript is getting interesting again, with Comet a major driver, it's a big deal that we now have the entire source tree for a Comet-style, server-side Javascript, application that's been proven in the real world.

AppJet also released appjet.jar when they discontinued the general server-side Javascript platform earlier this year. Unfortunately, the download link is broken on AppJet.com, so I don't know if there's any way to get hold of the official version. It does, however, live on as a cloud-hosted offering at JGate.

New features in APE 1.0:

• New and improved communication protocol :
  • Entirely using JSON and fully extensible.
  • Several commands can be nested in one request.
• New transport methods :
  • XHRStreaming : A single connection is used to send and receive data. Better performance
    and reduced transfer delays.
  • JSONP : Allows to place «cross-domain» requests.
• Support for BSD & Mac OS X (running the APE server) implemented by using KQueue
• ServerSide JavaScript (SSJS) Implemented by using TraceMonkey (Mozilla SpiderMonkey)
• Mootools support on the server side.
• Complete Server-Side JavaScript API:
• • Handling of users, RAWs, Commands, Channels, Sockets
  • Use of non-blocking sockets (Client & Server)
  • MySQL connector module
  • API for doing external HTTP requests
  • WebHooks
• Log files for errors, access and general information

They've also created an online comic book to get you familiar with what APE is all about.

Even PHP developers can write web applications that use all sorts of fancy long-polling.

That is what Leo said about his NGiNX HTTP push module:

This module turns Nginx into an adept HTTP Push and Comet server. It takes care of all the connection juggling, and exposes a simple interface to broadcast messages to clients via plain old HTTP requests. This lets you write live-updating asynchronous web applications as easily as their old-school classic counterparts, since your code does not need to manage requests with delayed responses.

NHPM fully implements the Basic HTTP Push Relay Protocol, a no-frills publisher/subscriber protocol centered on uniquely identifiable channels. It it an order of magnitude simpler and more basic than similar protocols (such as Bayeux). However, this basic functionality together with the flexibility of the server configuration make it possible to reformulate most HTTP Push use cases in Basic HTTP Push Relay Protocol language with very little application- and client-side programming overhead.

Configure NGiNX and write some code to talk to it.

My name is Jerod Venema, and I'm excited to write to you about our new Comet server for the Microsoft stack - WebSync. It is written in 100% managed C#, and uses IIS to reach incredibly high user concurrency. Despite being written in C#, we've made it easy to integrate other languages as well by pre-building client libraries and allowing generic HTTP requests to send messages.

There are many challenges in getting a Comet server to operate efficiently in any language, and the .NET environment delivers its own set of unique challenges. One of the biggest challenges we faced was how to make IIS "play nice" when scaling to tens of thousands of concurrent HTTP connections and message transactions. A great deal of time was spent minimizing the memory footprint (even to the point of lazy object construction), optimizing libraries, and digging through pages of profiler results. Multi-threading reared its ugly (but powerful) head on more than one occasion as we sought to take maximum advantage of multiple CPU cores while keeping locking and concurrency issues to a minimum. We even ended up writing a new lock-free data structure similar to a linked queue that allows us to perform multiple-writer add/remove operations - very helpful when dealing with large lists of clients and messages. Once all was said and done, we tested on a $500 Acer desktop and saw over 30,000 concurrent users and 25,000 messages per second. (We were pretty pumped when we saw some of those numbers coming through!)

Once we were satisfied with the server's performance, we set our sights on a JavaScript client. We had originally been using the Dojo Toolkit, but the overhead was more than what we wanted (it rang in at about 90k after compression, but before gzipping), so we wrote our own library that, when compressed and gzipped, comes across the wire at about 8k total (just over 15k before gzipping). We also ran into a slew of cross-browser issues (of course), in particular when dealing with long-lived HTTP connections. A bit of effort, though, and we can now claim the client to be fully compatible with over a dozen browsers, from IE5.5 all the way to the iPhone and Android browsers. Being fans of open-source technology (even in a Microsoft world), we decided to use the Bayeux transport protocol rather than develop our own, so any Bayeux-compliant client can link in to the server.

We also spent some time on making it easy to integrate into non-browser applications. One of the really neat features is the ability to publish data via a simple GET/POST request, so it can integrate into any application that can make a web request, regardless of the language. If you're writing in PHP or .NET, we've made life even easier by writing publishers that wrap up the creation and invocation of the web request into single method calls.

Oh, and we've got a hosted version too (WebSync On-Demand), so people with smaller sites who don't want the cost of hosting their own Comet server can still get all the benefits of a full Comet solution. For the On-Demand solution we've also implemented request proxing, which allows developers to direct the low-impact publish and subscribe requests to their server first, so they can pre-process any incoming messages (to add authentication, save messages to a database, etc). And again, for PHP or .NET users, it's a one-liner to implement.

Anyway, it's a pretty neat product, easy to get started with, and as I said, we're pretty excited and proud of it, so check it out including demos or tutorials and let us know what you think!

• Automatic Scaling: Jabbify scales to thousands of users per domain with no additional maintenance on your part.
• Instant setup: Download a script and you're developing with Comet in 30 seconds or less.
• Simple to use: Its easy. Really really easy. All you need is the JavaScript API or GET requests, technologies most developers are very familiar with. Simply connect and send your message.

Here's a graphic showing how the service works:

Here's an example of how to use Jabbify to send a message to all users connected to a domain:

The service is currently in beta and is free to use; further:

It will always be free for websites with a small number of concurrent users. We’ve tried to make it as easy as possible to get started with plenty of docs and demos. There’s:

* A downloadable page that runs from the filesystem
* A service overview page
* An API demo
* A keyboard demo
* An open source chat client demo
* API documentation

We’d love to chat with people to see what they think about a service like this.

We recently posted on Atmosphere, a new framework designed to provide an abstraction layer over Comet back-ends for Java web applications. At a personal level, this comes at an interesting time as over in the Mozilla Labs we're evaluating different Comet approaches for our upcoming collaboration release. As we looked at various options, we come across some recent postings from Ted Goddard of IceFaces fame explaining their work on making Comet as simple as possible for Java developers, including a podcast and an overview of the IceFaces approach.

Say what you will about JSF, their abstraction layer makes server and client implementation of Comet incredibly simple:

In other words, we can re-use our existing Ajax pipeline, and the application developer only needs to worry about one thing: requesting that a page be rendered. As you can imagine, this is only a few lines of code. With ICEfaces it looks like this:

PLAIN TEXT

JAVA:

1. SessionRenderer.addCurrentSession("ajaxian");
2.  
3. // somewhere else in the presentation tier
4. SessionRenderer.render("ajaxian");

Not only does the application developer not have to worry about low-level protocol details or messaging, they don't even have to worry about what has changed on the page -- this is all taken care of by the declared binding between the page and the model.

To summarize: we have dynamic pages that can be rendered on the server at any time, and the updates are pushed to the browser where the changes are applied to the DOM. From the application developer's point of view, that's all there is to it.

Are you using a stack that makes Comet this easy? Have you been able to successfully implement Comet? Do you get sufficient performance from polling?

Atmosphere 0.1-ALPHA1 is now officially released and support Tomcat, Jetty, Grizzly and GlassFish. Finally a Comet/Ajax Push framework you can build on top of it and deploy everywhere!

One of the cool features of this release is that it auto-detects which server back-end you've deployed it into.

Among the materials in the release notes are two code samples and a PDF discussing what Comet is and the motivation/design behind Atmosphere.

Comet on Java just got easier, which is a welcome development indeed.

I went along last night to the London Mozilla Labs meetup, where Dion, Ben, and Joe delivered a presentation on Bespin. These are my notes from the event.

Goals

Bespin - initially an experiment, now interested to see how far it can go as a coding environment (among other things).

"The editor of our dreams":

• Accessible from anywhere
• Simple to use, like Textmate - for people who don't want to muck around with low-level details, too much time in version control
• Wicked fast - many editors look okay initially but don't scale well with large files and fast editing
• Rock-solid real-time collaboration - like SubEthaEdit - watch people in our time, e.g. follow someone like Brendan Eich as he codes (given that it's already open source). One of the meta-goals here is to lower the barriers for open-source development.
• Integrated command-line, like Vi
• "Self-hosted" environment - like Emacs. As a programmer, can get into its guts. And can do this kind of thing in real-time - modify the model as it runs (c.f. Eclipse - must re-compile)

Demo

Dion demos interacting with the Bespin editor. (Always good to see how the creators eat their own dogfood.) Ben points out it's fast, thanks to Canvas. Some demos of the command-line, its extensibility, and collaboration features.

Collaboration

Moz hired Joe Walker of Comet/DWR fame a month ago. Joe explains collaboration goals.

Typical scenario - two coders working simultaneously, perhaps chatting over skype.

From Neil Fraser (worked on Google Docs stuff around this) - designed as a "little version control system" - sends out diffs and patches it (see Mobwrite. Bizzarely, the bottleneck is not the network or the patch, but the diff. And exarcebated by the fact that typing faster - doing more work - necessitates more diffing.

Joe shows debug messages in Firebug console - showing diff info going to and from the server

Extra Features

Code nav - heatmap showing all of code and what's been edited. recently. Example of a mashup component you can build.

e.g. IBM coder turned it into a Java compiler - by compiling the Java on the server. Used Bespin's server API. Likewise, the editor is also a distinct component - can use the editor for other (non-IDE) application - e.g. a wiki project using Bespin's editor to edit the wiki. Likewise, the command line is separate. And there's the underlying core, Thunderhead.

Ben further emphasises it's not just a rich client-side editor - server-side code analysis with the RESTful API.

Upcoming Features

Big things:

• Collaboration
• VCS integration - integrate with Mercurial, etc etc
• Ubiquity Integration
• Server Side Javascript - can have different server implementations, could be Ruby etc, and want to implement one in JS

Smaller:

• Some nice commands
• Plan "follow me!"
• Syntax highlighting
• Design concepts
• Templates ("create project Rails")
• Editor functionality
• ... many more - need people to help with it (engaging with the community and supporting contributions in an open-sourcey way is a big theme in this talk)

Fin

They leave us with a clip of Dave Thomas @ RubyConf asking if it's weird to love your software tools, and answering that you have to love your tools. Fair play!

Questions and Answers

Q. Distributed Version Control - will bespin support it? Bespin designed for two basic use cases (a) standard thing - check in to repo etc (b) bespin.mozilla.com - SAAS type model.

Q. What data structure is being used for patch sets? Because a decent structure would make VCS possible. Mobwrite - Neil Fraser's project behind Google Docs - so using that format, but we might expect it to change in the future.

Q. (me) Eating your own dogfood Dogfooding by end of month, when VCS lands or using Appcelerator Titanium to run off local file system.

Q. (about integration with Ubiqutiy I think?) Ubiquity as the runtime and Bespin for authoring. Initially, separate to Ubiquity and then normalised commands with Ubiquity. Now just starting to share components like parser. Next phase, access to virtually all of Ubiquity and will work even without Moz browsers. And the other way round - running Ubiquity commands inside Bespin.

Q. With the collaboration engine, can you do more than code creation, e.g. drawing or spreadsheets? Using Mobwrite, the engine behind Google Docs' collaboration - Mobwrite's restricted to text - as long as there are changes to some structure (ie it can be serialised), it's possible.

Q. Codes and tests in the cloud - should be great for continuous integration There are various people already implementing the Bespin server API for other things too. With the code out in the cloud, very possible to do all sorts of things with the code. John Resig (also Moz) is also interested in this area - also wrt manual tests that are downloaded to various people's browsers and run locally. Maybe could even be automated using the aggregate crowd while the browser isn't doing anything else. Another project is Test Pilot (usability testing).

(On a related note, I mentioned later on it would be interesting to couple the code with real-time user data, e.g. a heatmap overlay on the code showing how much resources each segment used during real-world use.)

Q. Hyperlinking in code? Could you create ~implicit links, e.g. to other parts of the code? Don't have hyperlinks because it's canvas! But will be able to implement these things - would be done as a syntax highlighter extension.

Q. Firstly, the name? Secondly, the offline capability - can I just run it directly off the local file system. With Appcelerator Titanium, would feel like a real desktop app while offline, but can still access the cloud when connected. (No-one answered the name question ;)

Q. Mashups in the browser - loads of scope for in-editor mashups, will it be part of the editor framework Right now, editor has an event bus - events like "he's opened the file, he's hit a key", so can set up events for this kind of thing. It's all based on an asynchronous model, so very possible.

Q. Will there be user testing - to see what people really want? There's a huge list in Bugzilla for these kinds of things. This is a tech preview, missing a ton of functionality. Already improved, but a lot more to do.

Q. Vim or Emacs macros - which will be first? Have implemented Elisp and Javascript, so it's only a matter of time. (cunningly avoided expressing a preference :)

Q. Functional reactive programming (FRP) - Flapjax demonstrates the idea in JS - for pubsub. Would it be possible to extend the current pubsub framework into a FRP framework - avoids bugs around order . Would be good to see something like that.

Q. Are you "re-inventing the web" with this stuff, i.e. finding that canvas doesn't support it? Yes, do have to reinvent a lot of things - people coming together to discuss these things - ARIA etc. Very focused on accessibility. Two ways to do it - (a) hacks like the cut-and-paste to mirror what's happening; (b) longer-term - drive the browsers forward.

Aside - Bespin currently leaks memory. Browsers are now runtimes, so want to build a tool for memory tracking. (a) Log each garbage collection. (b) Graphical view of the heap. After that, tool after that is meta - a directory of all the tools out there.

Q. On a much smaller scale, could it be used as a textarea? Yes, Firefox engineers were keen to look at that.

Q. How much implemented in Javascript? Very much the trend in Moz. cf. Aza Raskin's recent post on doing an extension in Javascript (*cough* Chrome *cough*). All the XUL stuff was necessary at the time. Javascript's not the bottleneck anymore.

Q. The name? (as was previously asked) So with that, let's wrap up.

My colleague Fred has also posted his impressions.

JSSO works like this:

The data-transfer and the connection to the server are maintained by a simple embedded Flashmovie in your page. The communication with other clients runs through the local Flashmovie and the Red5-Server.
The data-flow between two clients looks like this:

Javascript/jsSO - Flashmovie - Red5-Server - Flashmovie - Javascript/jsSO

And you would have Comet end points to play with?

That is what Malte has given us with a proof of concept called UniversalComet:

I have developed a JavaScript library that makes it extremely easy to incorporate "comet" or server-push technology into any web application without need for special programming or any special support on the server. Ressources needed on the server are also practically zero.

When you use the JavaScript library, you will receive an URI that identifies the client. Now you can make simple HTTP-GET requests to that URI with a message parameter and the client will receive the message immediately. Because only your application will know the un-guessable URI, the client should be save from unwanted messages. The use of HTTP-GET messages also allows sending messages in a "P2P"-fashion from client to client using JSONP cross-domain-messages.

The function that is passed to the connect-method receives the URI of the client and as soon as messages arrive they will be send to the onmessage-callback.

The JavaScript application uses "channels" to differentiate between different windows that the same client has open at any given time. These are cached in window.name. If you set window.name yourself this value is used. You can also set server.setChannel("myChannel") before you connect to name the channel yourself.

You can check out the demo.

Kaazing is happy to announce the second major release of its Kaazing Gateway, an open source HTML 5 web server, which includes support for HTML 5 WebSockets. With the 8.12 release of Kaazing Gateway delivers even more HTML 5 features such as Server-sent Events, more advanced security services, and extended support for XMPP (Jabber) and STOMP (e.g. ActiveMQ, RabbitMQ, or OpenMQ).

Server-sent events make a substantial contribution to the HTML 5 specification; however, Kaazing Gateway makes that contribution even greater by enabling Broadcast Notifications, which makes it possible to send messages from a TCP-, UDP-, or Multicast-origin and deliver simultaneous updates to tens of thousands of end-users. Applications of Server-sent event broadcasting include sporting event updates, system notifications, financial market updates, and much more.

Kaazing Gateway's HTML 5 emulation libraries also include a number of updates. The libraries now enable any modern browser to support HTML 5 Server-sent Events, and introduce support for HTML 5 postMessage, which facilitates cross document messaging. Kaazing's HTML 5 libraries also include support for HTML 5 Offline Storage, which provides simple DOM-based storage solution. Kaazing Gateway and its client libraries also now provide support W3C Access Controls for Cross-Site Requests, which is a mechanism to enable client-side cross-site requests, better known as Cross-site XmlHttpRequests.

Beyond extended support for HTML 5, Kaazing Gateway 8.12 also provides more advanced XMPP features such as group chat. This release also introduces STOMP-JMS Adapter, which allows you to adapt any existing Java Message Service (JMS) services (e.g. JBoss Messaging, Tibco EMS, OpenMQ, SwiftMQ, WebSphere MQ, etc. ) for use with Kaazing Gateway.

Kaazing has released Kaazing Gateway, an open source HTML 5 WebSocket Server.

The HTML 5 WebSocket specification is a standard that attempts to simplify much of the complexity around achieving bi-directional communications between browsers and servers. The specification provides a simple JavaScript interface that enables developers to open a full-duplex socket connection and connect directly to any TCP-based back-end service (for example, JMS, JMX, IMAP, Jabber, and so on).

Kaazing Gateway makes it possible for developers to take advantage of WebSockets today by providing a JavaScript library that emulates the HTML 5 WebSocket, making it possible to build applications that leverage the WebSocket interface and that can be deployed to both modern and future browsers.

The ultra high-performance server behind Kaazing Gateway can support tens of thousands of concurrent connections on a single node. Multiple instances can be clustered with traditional HTTP load-balancers or DNS round robin, making it possible to support any number of persistent client connections. In addition to large numbers of connections, Kaazing Gateway can also handle high data throughput thanks to its high-performance, staged event driven architecture (SEDA).

The Atlantis release of Kaazing Gateway also comes prepackaged with JavaScript clients for popular message services such as Apache ActiveMQ and RabbittMQ as well as clients for XMPP services such as OpenFire, Jabberd, and other popular chat servers. This makes it easy for you to quickly build web-based chat applications or messaging applications such as stock matrixes, online trading platforms, or online games.

What is the WebSocket API?

Ted Goddard answered a bunch of questions in WebSocket is neither Web nor Socket.

• Does WebSocket use TCP ports 81 and 815?
• How does WebSocket make use of an HTTP connection on port 80?
• Does WebSocket obey the same origin policy?
• Is WebSocket restricted to the two-connection limit of HTTP?
• Can WebSocket read and write arbitrarily as with low-level socket APIs?
• How does WebSocket delineate messages?
• How are function call semantics implemented over WebSocket?
• Is WebSocket easy to implement?
• Can we just upgrade HTTP?

Michael Carter had a fun little spin on things in HTML5 WebSocket and WebJneering.

I want to tell you about HTML5, specifically about the advances in bi-directional, asynchronous communication. But I’m troubled. Consider two propositions that I didn’t come up with: 1) Nothing is new, 2) Everything Sucks. Let these simple truths cast a shadow upon the tale you are about to read…

HTML5 provides a new thing called a WebSocket. I’m pretty sad that its not a TCPSocket, but alas, it was easier to throw in a handshake for security than to set up some out-of-bound security method, such as flash’s cross-domain policy files. We can’t connect to existing TCP servers, so we’ll just have to start over and write new WS/TCP servers. No problem. WebSocket will still be our salvation, leading us towards our stateful future.

I was at first overjoyed at the prospect of the World Wide Web’s new status as a real boy. But such feelings were just a precursor to the greatest technology-driven depression of my life. You see, as recently as twenty years ago the world was brimming with real programmers, who knew how to do such amazing things as write programs that conversed with far-away computers by using bsd sockets. We’ve traded those programmers, by and large, for JavaScript kiddies. Its not that the real programmers all died, retired, or gave up with programming; rather, every new programmer of the past decade is a bright-eyed 22 year old who thinks he’s the best thing since Google, what with his domination of rails (, java, or php) and javascript.

Both Michael and Ted will be joining myself, Alex Russell, Dylan, John Fallows, and others at an event tonight in Mountain View covering Comet. If you are in town, join us!

We are using the Google Moderator to help answer questions you want heard, so
add your questions too.

In this series I will detail what I found out empirically about how mochiweb performs with lots of open connections, and show how to build a comet application using mochiweb, where each mochiweb connection is registered with a router which dispatches messages to various users. We end up with a working application that can cope with a million concurrent connections, and crucially, knowing how much RAM we need to make it work.

In part one:

• Build a basic comet mochiweb app that sends clients a message every 10 seconds.
• Tune the Linux kernel to handle lots of TCP connections
• Build a flood-testing tool to open lots of connections (ye olde C10k test)
• Examine how much memory this requires per connection.

Future posts in this series will cover how to build a real message routing system, additional tricks to reduce memory usage, and more testing with 100k and 1m concurrent connections.

Richard walks through the code and setup, step by step and measures the scalable performance, leading too:

That was a reasonable first attempt. 45KB per-connection seems a bit high - I could probably cook something up in C using libevent that could do this with closer to 4.5KB per connection (just a guess, if anyone has experience please leave a comment). If you factor in the amount of code and time it took to do this in Erlang compared with C, I think the increased memory usage is more excusable.

In future posts I’ll cover building a message router (so we can uncomment lines 25 and 41-43 in mochiconntest_web.erl) and talk about some ways to reduce the overall memory usage. I’ll also share the results of testing with 100k and 1M connections.

Michael Carter et al have been working on js.io, a client library that gives you networking, including Comet like support, via JavaScript.

The low level work can sit upon Comet APIs, and in the future, Web Sockets, and you get high level APIs to protocols such as:

• amqp
• imap
• irc
• ldap
• smtp
• ssh
• stomp
• telnet
• xmpp

There are some demos such as LiveHelp that uses Orbited as the backend.

• Comet server push
• Customization of look and feel
• Performance monitoring

Server push via polling has been available in ZK for a while, and Comet in the ZK "Enterprise Edition," but now it is available to everyone. And it is pretty easy to use: "The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable."

Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.

Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:

• T1, the time browser sends a request to server
• T2, the time server receives a request
• T3, the time server sends a request to browser
• T4, the time browser receives a request from server
• T5, the time the browser finishes processing a request

ZKStudio 0.8.2

There's also a new version of ZKStudio for Eclipse out. The major change is that it now supports auto update via http://studioupdate.zkoss.org/studio/update