Have one to sell? Sell yours here
Programming Flash Communication Server
 
 
Tell the Publisher!
I’d like to read this book on Kindle

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Programming Flash Communication Server [Paperback]

Brian Lesser , Giacomo Guilizzoni , Joey Lott , Robert Reinhardt , Justin Watkins


Available from these sellers.


‹  Return to Product Overview

Product Description

Product Description

With the advent of Flash Communication Server MX (FCS), Macromedia believes that it's on the edge of a breakthrough in how people think about the Internet. FCS has been designed to provide web developers with the means to add polished interactive audio and video features to their sites, the sort of features that users have come to expect.

Naturally, the process of efficiently integrating rich media into applications, web sites, and web content is a complex one, to say the least. That's where Programming Flash Communication Server factors in. As the foremost reference on FCS, it helps readers understand how FCS can facilitate:

  • Video on demand
  • Live webcasts
  • Video chat and messaging
  • Shared desktop conferences
  • Live auctions
  • Interactive whiteboard presentations
  • Workflow collaboration
  • Multi-user games
Programming Flash Communication Server not only explains how to use the pre-built FCS components to construct a simple application, it also explains the architecture so that developers can program custom components to make even more advanced applications. In addition, the book explains how to truly optimize performance, and talks about considerations for networked applications as well as the media issues pertaining to FCS.

Programming Flash Communication Server gives developers a sorely needed leg up on this potentially intimidating technology. It lets users develop cool web applications ranging from direct dating experiences with real-time video, to pre-recorded corporate presentations, to news services with video and audio, and much more.

At last, the ability to build web sites with rich interactive features--minus the complex downloads and installation hassles--is a reality. And now, with Programming Flash Communication Server from O'Reilly by your side, you can do more quickly and easily than you ever dreamed possible.

From the Publisher

Flash Communication Server MX (FCS) provides web developers with the means to add rich, interactive audio and video features to their sites. Programming Flash Communication Server gives developers a leg up on this potentially intimidating technology. It explains how FCS can facilitate video on demand, live webcasts, video chat and messaging, real-time collaboration, and much more.

About the Author

Brian Lesser works at Ryerson University as Assistant Director, Application Development and Support in Ryerson's Computing and Communications Services.

Giacomo "Peldi" Guilizzoni is a software engineer working on Macromedia Breeze Live, possibly the most complex Rich Internet Application powered by Flash Communication Server ever built. He has been involved in the FlashCom community since the very beginning and to this day maintains the only FlashCom-centered blog on the Web at http://wwwpeldi.com/blog.

Joey Lott is a founding partner of The Morphic Group, a Flex and Flash consulting company. At The Morphic Group Joey serves as a technology director, building some of today's most innovative Flex applications and advocating for the use and adoption of agile software development methodologies. He has written many books on Flex and Flash-related technologies, including Programming Flex 3, ActionScript 3 Cookbook, Adobe AIR in Action, and Advanced ActionScript 3 with Design Patterns.

Robert Reinhardt is the lead co-author of the Flash Bible series and the Flash MX ActionScript Bible (Wiley), as well as the lead co-author of Rich Media MX: Building Multi-User Systems with Macromedia MX Software (Macromedia Press).

Justin Watkins is the senior multimedia programmer for Career Education Group. Justin leads a team of Flash programmers and developers to produce synchronous and asynchronous applications that thousands of online students use daily. Justin is one of the lead developers on the open source PHP alternative for Flash Remoting. Justin has contributed articles to devmx (http://www.devmx.com), a community-based Web site for Macromedia developers.

Excerpted from Programming Flash Communications Server by Robert Reinhardt, Dave Yang, Brian Lesser. Copyright © 2005. Reprinted by permission. All rights reserved.

CHAPTER 1 Introducing the Flash Communication Server

Macromedia Flash has evolved from a way to easily create and distribute lightweight animated graphics on the Web to a rich application platform. Macromedia reported that Flash Player 6 was available on more than 94% of Internet-accessible workstations in Canada, the United States, and Europe as of June 2004. Availability in Asia exceeded 92%. Flash Player 7 penetration ranged from 67% in the U.S. to 81% in Europe. (For the latest statistics, see macromedia.com/software/player_census/flashplayer/version_penetration.html.) Flash Player 6 and 7 provide some remarkable capabilities to the hundreds of millions of machines on which they are already installed. With the user’s consent, a Flash movie can capture real-time audio and video from the machine’s microphone or web cam and stream it to Flash Communication Server MX. (Here we use the term movie to refer to .swf files. We use the term video for visual content streamed from the server.) The server can redistribute the streams to other users who have the Flash Player. The resulting real-time communications make it possible to develop a remarkable range of compelling applications. The Flash authoring tool and the Flash Communication Server MX can be used to create:

• Highly customized video conferences, team meetings, and web chats with shareable components such as versioned text areas, whiteboards, and instant polls

• Video- and data-on-demand applications with rich user interfaces that can include closed captions and skinnable controls

• Live event broadcasting with customizable user interaction such as moderated chat and question/answer components

• Multiplayer games, simulations, and other applications with the added value of audio and video if required

Flash and the Flash Communication Server MX (FlashCom) provide a rich development environment in which applications that clearly match requirements can be created without an outrageous investment in development time. The Flash Player and FlashCom support a rich set of objects that make sharing real-time audio, video, and data remarkably simple. In addition, Flash provides a set of user interface components such as the DataGrid, Tree, ComboBox, Accordion, and MenuBar, among others. The Flash authoring tool includes a full complement of tools for manually or programmatically generating vector graphics and animations, making it possible to create unique and rich custom user interfaces that can present and update data including audio and video. See the Preface for additional important details about the video delivery options made available by Flash and the FlashCom Server.

Clients and Servers
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.

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 chat-Room 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.

‹  Return to Product Overview