Flash Communication Server

In 1994, I was working for Novell, developing a toolkit that allowed application programmers to write once and compile and deploy anywhere (similar to Java, Director, and Flash). In October of 1994, Novell decided to get out of this business. I had an opportunity to work for a different group or take a fat severance check and find another job. I decided to take the layoff and the check!

Dan Greening, who was the director of engineering for my group at Novell, asked me if I would be interested in starting a company. At that time, there was a lot of buzz about the Internet and I felt the timing was perfect to take some risks. Dan and I, along with two other Novell alumni, Ron Lussier and Glenn Crocker, started Chaco Communications, Inc., in November 1994. We spent the next couple of months exploring multiuser role-playing games.

During the next year, we developed a Chaco client that used VRML to represent the virtual world. The VRML client didn't succeed, but I learned many lessons from its failures. We had developed a client that could be customized using HTML and VRML, but there was no authoring tool. The product was a standalone client, not integrated with the browser, so it required a separate installation. Server-side extension was difficult, limiting its customizability. Creating content was not easy, and that was a big problem. VRML as a technology was ahead of the hardware, which wasn't yet capable of an immersive 3D experience, and broadband was not yet widely available.

In 1996, NTT of Japan noticed Chaco's MUD (multiuser domain/dungeon/dimension) client and approached us to build a Java-based client and server for children, based on the Hello Kitty theme. We delivered this product in 1997, and it was very popular in Japan. The requirement for this project was to create an extensible client that ran inside a browser with a seamless install. We picked Java, which was the most ubiquitous client at the time. This proved very successful and showed me the importance of a ubiquitous client and an easy-to-customize application with the right authoring and development tools.

In 1997, Chaco merged with Songline Studios (owned by O'Reilly) to form LikeMinds. We changed direction, and I started work on a personalization server, intended to customize the web experience for repeat visitors to a given site. For the next 3 years, I was deep in the world of real-time data mining. This product was used by companies like NetFlix, Columbia House, and a bunch of dot-com retailers, many of which are no longer in business. Working on the LikeMinds personalization server, I learned a lot about building highly scalable servers in terms of moving large amounts of data in and out, managing large numbers of connections, interfacing with other systems, and so on.

While working on the LikeMinds social server, which was a chat server that we developed for NTT, we needed a data synchronization scheme, and I came up with something called distributed buckets. This was little more than name/value pairs plus a mechanism to replicate the name/value on all clients when any client added to a distributed bucket. I later used a similar design in the Flash Communication Server, and we called it shared objects.

LikeMinds was acquired by Andromedia, which was in turn acquired by Macromedia in 1999. Toward the end of 2000, Macromedia sold LikeMinds' technology to IBM, and it is now part of the IBM WebSphere personalization engine. I was still working for Macromedia when they decided to get out of personalization technology. I started exploring other opportunities, but I wanted to stick with server-side development. At that time, Macromedia did not have a lot of server-side technology; one product I considered was Generator. Before I had made a decision, I got a call from Jonathan Gay (the Father of Flash) who asked me if I would be interested in exploring a new project.

Jon had this idea of building real-time communication capabilities into the client-side Flash Player and wanted to know if I could help him build a server product to provide the server-side functionality. This brought back memories of my Chaco days. I felt that the time was right to again venture into the world of multiuser collaboration. Given my earlier experience of building multiuser communication products and knowing the reasons for its failures, I felt that with the combination of Flash Player, broadband, and the adoption of communication technologies like IM, there was a huge opportunity to move the technology to the next level by introducing audio and video. Combined with the multimedia capabilities of Flash, we had a realistic chance of succeeding, and I felt I could make a significant contribution in making this a reality.

For the next 4 months, we did an extensive study of the market, technologies, and trends to see what we should build. Our vision was to build a real-time communication infrastructure to take Flash and Macromedia into a new, profitable business in the telecommunications world. Flash's adoption as the standard for web animation was made possible by providing a lightweight Player and a rich, easy-to-use authoring system that provides a set of high-level APIs approachable by a large audience. We wanted to continue this vision by providing a platform for real-time communications that was easy to develop for and deploy. To better understand what this platform had to provide, we put together ideas for 10 real-time applicationsclassroom, company meeting, front door cam, customer service, car race, remote presence, and so onand collected all the requirements to come up with the base features. All applications required some combination of audio, video, or data as streams (some real-time and some on-demand) and data synchronization. They all required an application model to create and control groups, which resulted in the server-side application model defined by Flash Communication Server.

This resulted in the following features the platform needed to provide:

An easy-to-install, ubiquitous client supporting multimedia devices such as microphones and cameras
A low-overhead protocol with support for real-time delivery of media, data, and control messages
Real-time or stored (on-demand) data
Software applications that add intelligence and support communication
An easy way to blend content and communication
Support for remote presence

The first two items on the list describe the Flash Player and the RTMP protocol. But to succeed, we also needed to provide a simple, reliable, and flexible model for communications and application development, with a high-level API for developers. Furthermore, we needed to set application development standards and help the developer community understand how to build communication applications.

Despite the misperception that Flash Communication Server (FlashCom) was based on Shockwave Multiuser Server (SMUS), a multiuser server once provided with Macromedia Director, FlashCom was built from the ground up. FlashCom provides features never available in SMUS, such as shared objects and the publish-subscribe model for audio, video, and data streams. That is not to say FlashCom didn't borrow from my past projects in real-time collaborative software. As I said, the distributed buckets in LikeMinds' social server became FlashCom shared objects. And I had developed a high-performance socket I/O architecture for the LikeMinds server that became the core I/O architecture for FlashCom. Of course, FlashCom provided new challenges, for which I developed the RTMP protocol (with help from Jon Gay and Brad Edelman), its server-side object model, on-demand streaming, the FlashCom application model, and the configuration model.

After nearly 2 years of development, Macromedia released Flash Communication Server MX 1.0 in September 2002. FlashCom version 1.5 followed in March 2003, and the latest update, version 1.5.2, was released in May 2004. We succeeded in defining a new application development platform for real-time communication applications. Looking back at the vision and value we pursued, I am very proud to say that we delivered on our promise. We may have had some unrealistic optimism about its instant success, but over the last year, we have seen Flash Communication Server establish a toehold in the market, and now we are seeing our dreams realized.

One of the challenges with any new technology is finding early adopters who can invest in an unproven technology. This problem was compounded by the fact that the Internet bubble burst, and developing a collaboration application requires a new skill set and significant resources. Given this slow adoption, we decided it was time for us to eat our own dog food and show what could be done with FlashCom, so we built Breeze Live atop the FlashCom platform. Breeze Live is probably one of the most complex FlashCom applications ever developed and has greatly benefited me in evolving the core FlashCom platform. And Breeze Live is one of Macromedia's fastest-growing products, proving that there is a market for compelling, media-rich, real-time communication applications.

Another key to the success of any platform is teaching developers how to build applications beyond "hello world." I am confident that Programming Flash Communication Server will go a long way in making this adoption possible. It is a must-read book for anyone serious about writing communication applications using Flash Communication Server.

Pritham Shetty

Principal Architect

Flash Communication Server

Macromedia