More Books
Flash Communication Server
Flash Communication Server
Table of Contents
Copyright
About the Authors
Brian Lesser
Giacomo
Joey Lott
Robert Reinhardt
Justin Watkins
Foreword
Preface
What Does FlashCom Offer?
What's in This Book?
How to Use This Book
Audience
ActionScript 1.0 Versus ActionScript 2.0
Server-Side ActionScript
The flash-communications.net Site
Director, Breeze, and Other Options
Flash Video Options
Licensing and Hosting Options
Conventions Used in This Book
Voice
Using Code Examples
Safari Enabled
Comments and Questions
Acknowledgments
Part I:  FlashCom Foundation
Chapter 1.  Introducing the Flash Communication Server
Section 1.1.  Clients and Servers
Section 1.2.  Creating an Application
Section 1.3.  Real-Time Messaging Protocol
Section 1.4.  The Communication Classes
Section 1.5.  Communicating with Application Servers, Databases, and Directory Servers
Section 1.6.  Firewalls and Security
Section 1.7.  Getting Started
Section 1.8.  Hello Video!
Section 1.9.  Conclusion
Chapter 2.  Communication Components
Section 2.1.  Overview of Communication Components
Section 2.2.  Summary of Communication Components
Section 2.3.  Creating an Application that Monitorsa Connection
Section 2.4.  Building a Simple Chat Room
Section 2.5.  Adding Audio and Video to the Chat Room
Section 2.6.  Forgoing the SimpleConnect Component
Section 2.7.  Conclusion
Chapter 3.  Managing Connections
Section 3.1.  Making a Connection
Section 3.2.  Managing a Connection
Section 3.3.  Reusing a NetConnection Object
Section 3.4.  Multiple Simultaneous NetConnection Objects
Section 3.5.  Testing and Debugging Network Connections
Section 3.6.  Subclassing the NetConnection Class
Section 3.7.  Communication Components Without SimpleConnect
Section 3.8.  Conclusion
Chapter 4.  Applications, Instances, and Server-Side ActionScript
Section 4.1.  Scripting Application Instances
Section 4.2.  Differences Between Flash ActionScript and Server-Side ActionScript
Section 4.3.  The Life of an Application Instance
Section 4.4.  Running a Simple Hello World Test Script
Section 4.5.  A More Realistic Example
Section 4.6.  Instance-to-Instance Communications
Section 4.7.  Script Filenames and Locations in Detail
Section 4.8.  Testing and Debugging Server-SideScript Files
Section 4.9.  Designing Communication Applications
Section 4.10.  Conclusion
Part II:  Audio, Video, and Data Streams
Chapter 5.  Managing Streams
Section 5.1.  A Simple Publisher/Subscriber Example
Section 5.2.  Stream Names
Section 5.3.  Publishing Streams in Detail
Section 5.4.  Playing Streams in Detail
Section 5.5.  The Stream Class
Section 5.6.  Publishing and Playing ActionScript Data
Section 5.7.  Creating Synchronized Presentations
Section 5.8.  The NetStream and Stream Information Objects
Section 5.9.  Stream Enhancements and Limitations
Section 5.10.  Conclusion
Chapter 6.  Microphone and Camera
Section 6.1.  Working with Microphone/Audio Input
Section 6.2.  Working with Camera Input
Section 6.3.  Building a Message-Taking Application
Section 6.4.  Building a Surveillance Application
Section 6.5.  Conclusion
Chapter 7.  Media Preparation and Delivery
Section 7.1.  Audio and Video Compression
Section 7.2.  Converting Prerecorded Materialto FLV Format
Section 7.3.  Using Flash Pro's Media Components
Section 7.4.  Enabling Multiple Bit Rate FLVsWithin an Application
Section 7.5.  Streaming MP3 Audio
Section 7.6.  Conclusion
Part III:  Remote Connectivity and Communication
Chapter 8.  Shared Objects
Section 8.1.  Objects and Shared Objects
Section 8.2.  Getting a Shared Object in Flash
Section 8.3.  Updates and Frame Rates
Section 8.4.  Scripting Shared Objects on the Server
Section 8.5.  Temporary and Persistent Shared Objects
Section 8.6.  Proxied Shared Objects
Section 8.7.  Shared Objects and Custom Classes
Section 8.8.  Avoiding Collisions
Section 8.9.  Optimizing Shared Object Performance
Section 8.10.  Broadcasting Remote Method Callswith send( )
Section 8.11.  A Simple Video and Text Chat Application
Section 8.12.  Conclusion
Chapter 9.  Remote Methods
Section 9.1.  Why Use Calls?
Section 9.2.  The send( ) and call( ) Methods
Section 9.3.  Client-to-Server Calls
Section 9.4.  Server-to-Client Calls
Section 9.5.  Server-to-Server Calls
Section 9.6.  A Simple Lobby/Rooms Application
Section 9.7.  Debugging Calls
Section 9.8.  Advanced Topics
Section 9.9.  Conclusion
Chapter 10.  Server Management API
Section 10.1.  Connecting to the Admin Service
Section 10.2.  Using the Server Management API
Section 10.3.  Server Management API Uses
Section 10.4.  Conclusion
Chapter 11.  Flash Remoting
Section 11.1.  The Remoting Gateway
Section 11.2.  Remoting Basics
Section 11.3.  Role of Remoting in FlashCom Applications
Section 11.4.  Securing Access
Section 11.5.  Conclusion
Chapter 12.  ColdFusion MX and FlashCom
Section 12.1.  Understanding ColdFusion MXand Flash Remoting
Section 12.2.  Using Flash Remoting to Log Events
Section 12.3.  Getting a List of Streams
Section 12.4.  Using ColdFusion and FTP to Mirror Streams
Section 12.5.  Conclusion
Part IV:  Design and Deployment
Chapter 13.  Building Communication Components
Section 13.1.  Source Files
Section 13.2.  People Lists
Section 13.3.  A Simple People List
Section 13.4.  Listenable Shared Objects
Section 13.5.  Status and People List
Section 13.6.  Text Chat
Section 13.7.  Shared Text
Section 13.8.  Video Conference and Video Window
Section 13.9.  PeopleGrid
Section 13.10.  Summary
Section 13.11.  Conclusion
Chapter 14.  Understanding the Macromedia Component Framework
Section 14.1.  The Component Framework
Section 14.2.  Under the Hood of the Chat Component
Section 14.3.  Creating a Simple Component from Scratch: SharedTextInput
Section 14.4.  Creating a Container Component: SharedAddressForm
Section 14.5.  Creating an Authenticating Component
Section 14.6.  Integrating Components with Your Existing Applications
Section 14.7.  Understanding the Framework
Section 14.8.  Conclusion
Chapter 15.  Application Design Patterns and Best Practices
Section 15.1.  Shared Object Management
Section 15.2.  Moving Code to the Server
Section 15.3.  Building Façades on the Server
Section 15.4.  Server-Side Client Queues
Section 15.5.  A Framework for Recording and Playing Back Componentized Applications
Section 15.6.  Components and Component Frameworks
Section 15.7.  Conclusion
Chapter 16.  Building Scalable Applications
Section 16.1.  Coordinating Instances
Section 16.2.  Scalability and Load Balancing
Section 16.3.  Conclusion
Chapter 17.  Network Performance, Latency,and Concurrency
Section 17.1.  Latency
Section 17.2.  Bandwidth
Section 17.3.  Concurrency
Section 17.4.  Conclusion
Chapter 18.  Securing Applications
Section 18.1.  The Three A's: Authentication, Authorization, and Accounting
Section 18.2.  Authentication
Section 18.3.  Authorization
Section 18.4.  Accounting
Section 18.5.  Suggestions and References
Section 18.6.  Conclusion
Index
SYMBOL
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
R
S
T
U
V
W

4.8. Testing and Debugging Server-SideScript Files

Currently, no debugger that provides a way to examine data directly or step through code is available for testing and debugging server-side scripts. The primary way to get a view into the state of an executing script is to use trace( ) statements to output information. Trace output can be examined in different ways.

The NetConnection Debugger, discussed in "Using the NetConnection Debugger" in Chapter 3, will list trace( ) events under its Events tab and the output under its Details tab. This is most useful when you are working on a Flash movie and want to see server-side output as you make changes to the movie and have it connect and reconnect to FlashCom.

To test and fix server-side code, the primary tool for seeing trace output is the App Inspector movie (app_inspector.swf). Whenever a change is made in a server-side script, the instance must be reloaded so that the source files that contain the updated code are recompiled and executed. The App Inspector can be used to load, reload, and unload an application instance at any time. You can also easily select any running instance from a list and view connection and bandwidth statistics, stream and shared object status, and a live log that includes system messages and trace output.

Unlike other server development environments, trace output cannot easily be piped to a text file for later examination. However, FlashCom does provide a facility to record trace output in a recorded stream file. To enable application logging (Macromedia's term for recording trace output), an Application.xml file must contain the XML tag and value as follows:

<RecordAppLog>true</RecordAppLog>

Logging can create very large files over time, so it is often best to not make this adjustment in an Application.xml file for an entire virtual host. An Application.xml file can be placed in the home directory of the application that is being developed. When logging is turned on, a stream file with an .flv extension and named after the instance will be saved within a folder named after the application within the applications/admin/streams/logs/application directory. The file can be read using the Flash Communication Server Log reader available as a separate download from Macromedia. Please see Technote 16464:

http://www.macromedia.com/support/flashcom/ts/documents/flashcom_logging.htm

There are other alternatives for generating log output and log files. Flash Remoting can be used to send data to an application server where it can be stored in a database or written to a text file. When Remoting is used, a custom logging function must be called in place of trace( ). Similarly, custom Flash clients can receive data via remote method calls where they can sort and analyze data before presenting it. Remoting is described in Chapter 11, and remote method calls are covered in Chapter 9. An application-level logging system is discussed in Chapter 12.

4.8.1. Organizing Test Scripts

During program development and testing, load( ) can be used to make testing of many different SSAS files a little easier to manage. If you had to create a new application home directory for every test script, you would end up with many different test folders. One trick is to use different instances to test different scripts within a single application home directory. One way to do this is to create a main.asc file with this one statement in it:

load(application.name.split('/').pop(  ) + ".asc");

Then you can create as many test files as you like in the application's home directory. To run a test file, connect to an instance of your application with the same name. Suppose, for example, you are working on an application named courseChat and want to run different versions of the application's main file. You may have several main files named mainVersion1.asc, mainVersion2.asc, and so on. You can run any one of these files by using the App Inspector to load the right instance name, such as courseChat/mainVersion2, and then reload it to check the output. If client interaction is required, a test client can be set up to connect to rtmp:/courseChat/mainVersion2.

Using the main.asc file to load other files in the application's home directory works well for testing different main file versions. When a main file is ready to go into production, it can be moved into a production directory and renamed main.asc.

Testing individual objects and functions is also an important part of developing applications, and you may not want to clutter the application home directory with many test script files. As an alternative, a main.asc file can be created that contains this short script:

this.tempPath = application.name.split("/");
this.tempPath.shift(  );
load(this.tempPath.join("/") + ".asc");
//delete this.tempPath;  // Uncomment this if you want to delete tempPath.

The script will load files based on the full instance name. For example, if a client connects to an instance named rtmp:/courseChat/testBed/userClassTests, then the userClassTests.asc file in the testBed directory will be loaded and executed.