Introducing the Flash Communication Server

FlashCom is a server-side application that is installed on a host machine much like a web server; however, FlashCom works very differently than a web server. Instead of accepting many brief connections from browsers requesting a web page or other resource, FlashCom accepts persistent connections from Flash movies running in a Flash Player. Each Flash movie can share data with other Flash movies via the server using Macromedia’s proprietary Real-Time Messaging Protocol (RTMP). Unlike the HTTP request/response model used by browsers to communicate with web servers, the Flash Player’s RTMP connection to the FlashCom Server is persistent, so no special steps are needed to maintain session information. Once the server accepts a client connection, the connection can be used to exchange audio, video, and ActionScript data until either the client or server disconnects.

The Flash Player may be running within the Standalone Player or within a web browser. The Flash Player (and any movie playing within it) is considered the client. FlashCom cannot initiate a connection to a movie; the connection must be initiated from the Flash Player running on the client. Let’s review the architecture briefly so you can understand all the pieces to the puzzle. The client/server architecture for FlashCom applications is shown in Figure 1-1.

Web browsers load Flash movie files (.swf files), load the Flash Player, and pass the .swf file to the Player to execute. The Flash movie provides the user interface and can attempt to connect via the Player to any FlashCom Server. Once connected, the Flash movie can communicate with the server. Furthermore, it can communicate—via the server—with movies playing on other Flash clients. A Flash movie can stream audio and video to the FlashCom Server so that other Flash clients with access to the same server can play recorded streams stored on the server and live streams from other clients.

A live stream is usually one that is published to the server by one client so that other clients can receive it. As the client’s data arrives at the server, the server duplicates it and forwards it to each client, where it is seen and heard. In contrast, recorded streams are stored on the server and can be played from any point within the stream, paused, and restarted. It is also possible to stop a recorded stream, seek to any point within it, and begin playing again.

If multiple FlashCom Servers are connected to one another, clients connected to one server may be able to communicate with clients connected to another server. The ability to communicate between servers and the clients connected to them makes possible large-scale applications, such as live event streaming to many thousands of viewers.

Figure 1-1.  Client/server architecture for FlashCom applications

FlashCom can host many different applications. More than one instance of an application can be run at the same time. Each instance is given its own unique name. When a client connects to the server, it always connects to an instance of an application by name. For example, many separate instances of an application named chatRoom may be available. Each instance has its own unique name and may provide unique resources for the client. Figure 1-2 illustrates three clients connected to the same instance of the chatRoom application.

Figure 1-2.  Three Flash movies connected to a FlashCom application instance via the Flash Player