Macromedia Flash Communication Server MX 1st ed Edition Kevin Towes 2024 scribd download

Download the full version of the ebook at
https://ebookultra.com
Macromedia Flash Communication Server MX 1st

ed Edition Kevin Towes
https://ebookultra.com/download/macromedia-flash-
communication-server-mx-1st-ed-edition-kevin-
towes/
Explore and download more ebook at https://ebookultra.com

Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.
Sams Teach Yourself Macromedia Flash MX 2004 in 24 Hours

Sams Teach Yourself Phillip Kerman
https://ebookultra.com/download/sams-teach-yourself-macromedia-flash-
mx-2004-in-24-hours-sams-teach-yourself-phillip-kerman/
ebookultra.com
Macromedia ColdFusion MX Development 1st Edition Eric Ladd
https://ebookultra.com/download/macromedia-coldfusion-mx-
development-1st-edition-eric-ladd/
ebookultra.com
How To Use Macromedia Dreamweaver MX and Fireworks MX 1st

Edition Lon Coley
https://ebookultra.com/download/how-to-use-macromedia-dreamweaver-mx-
and-fireworks-mx-1st-edition-lon-coley/
ebookultra.com
Flash MX Games ActionScript for Artists Nik Lever
https://ebookultra.com/download/flash-mx-games-actionscript-for-
artists-nik-lever/
ebookultra.com
Flash MX ActionScript Designer s Reference 1st Edition
Sham Bhangal
https://ebookultra.com/download/flash-mx-actionscript-designer-s-
reference-1st-edition-sham-bhangal/
ebookultra.com
How to do everything with Macromedia Flash 1st Edition

Bonnie Blake
https://ebookultra.com/download/how-to-do-everything-with-macromedia-
flash-1st-edition-bonnie-blake/
ebookultra.com
Flash MX 2004 at Your Fingertips Get In Get Out Get

Exactly What You Need 1st Edition Sham Bhangal
https://ebookultra.com/download/flash-mx-2004-at-your-fingertips-get-
in-get-out-get-exactly-what-you-need-1st-edition-sham-bhangal/
ebookultra.com
Managerial communication 1st ed Edition Bell
https://ebookultra.com/download/managerial-communication-1st-ed-
edition-bell/
ebookultra.com
Server study guide 2nd ed Edition Brad Hryhoruk
https://ebookultra.com/download/server-study-guide-2nd-ed-edition-
brad-hryhoruk/
ebookultra.com
Macromedia Flash Communication Server MX 1st ed
Edition Kevin Towes Digital Instant Download
Author(s): Kevin Towes
ISBN(s): 9780735713338, 0735713332
Edition: 1st ed
File Details: PDF, 2.42 MB
Year: 2002
Language: english
Developing Communication
Applications
Macromedia Flash Communication Server MX
™
macromedia ®
Trademarks
Afterburner, AppletAce, Attain, Attain Enterprise Learning System, Attain Essentials, Attain Objects for Dreamweaver,
Authorware, Authorware Attain, Authorware Interactive Studio, Authorware Star, Authorware Synergy, Backstage, Backstage
Designer, Backstage Desktop Studio, Backstage Enterprise Studio, Backstage Internet Studio, Design in Motion, Director,
Director Multimedia Studio, Doc Around the Clock, Dreamweaver, Dreamweaver Attain, Drumbeat, Drumbeat 2000, Extreme
3D, Fireworks, Flash, Fontographer, FreeHand, FreeHand Graphics Studio, Generator, Generator Developer’s Studio, Generator
Dynamic Graphics Server, Knowledge Objects, Knowledge Stream, Knowledge Track, Lingo, Live Effects, Macromedia,
Macromedia M Logo & Design, Macromedia Flash, Macromedia Xres, Macromind, Macromind Action, MAGIC, Mediamaker,
Object Authoring, Power Applets, Priority Access, Roundtrip HTML, Scriptlets, SoundEdit, ShockRave, Shockmachine,
Shockwave, Shockwave Remote, Shockwave Internet Studio, Showcase, Tools to Power Your Ideas, Universal Media, Virtuoso,
Web Design 101, Whirlwind and Xtra are trademarks of Macromedia, Inc. and may be registered in the United States or in other
jurisdictions including internationally. Other product names, logos, designs, titles, words or phrases mentioned within this
publication may be trademarks, servicemarks, or tradenames of Macromedia, Inc. or other entities and may be registered in
certain jurisdictions including internationally.
Third-Party Information
Speech compression and decompression technology licensed from Nellymoser, Inc. (www.nellymoser.com).
Sorenson™ Spark™ video compression and decompression technology licensed from

Sorenson Media, Inc.
This guide contains links to third-party websites that are not under the control of Macromedia, and Macromedia is not
responsible for the content on any linked site. If you access a third-party website mentioned in this guide, then you do so at your
own risk. Macromedia provides these links only as a convenience, and the inclusion of the link does not imply that Macromedia
endorses or accepts any responsibility for the content on those third-party sites.
Copyright © 2002 Macromedia, Inc. All rights reserved. This manual may not be copied, photocopied, reproduced,
translated, or converted to any electronic or machine-readable form in whole or in part without prior written approval of
Macromedia, Inc.
Acknowledgments
Director: Erick Vera
Producer: JuLee Burdekin
Writing: Jay Armstrong, Jody Bleyle, JuLee Burdekin, Barbara Herbert, and Barbara Nelson
Editing: Mary Ferguson, Anne Szabla
Multimedia Design and Production: Aaron Begley and Benjamin Salles
Print Design, Production, and Illustrations: Chris Basmajian
First Edition: May 2002
Macromedia, Inc.
600 Townsend St.
San Francisco, CA 94103
CONTENTS
INTRODUCTION
About This Manual .................................................. 5
Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
About the Flash Communication Server documentation . . . . . . . . . . . . . . . . . . . . . . . . . 5
Typographical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Additional resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CHAPTER 1
About Flash Communication Server .................................. 7
Overview of Flash Communication Server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Flash Communication Server objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Applications and application instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
File types used by Flash Communication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Setting up your development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Connecting to the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Writing your first application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CHAPTER 2
About Flash Communication Server Applications . . . . . . . . . . . . . . . . . . . . . 23
About Flash Communication Server services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
The Flash Communication Server design model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Designing Flash Communication Server applications . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CHAPTER 3
Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
About the samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Sample 1: Recording a Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sample 2: Shared Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Sample 3: Shared Ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Sample 4: Hello Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Sample 5: Text Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Sample 6: Record a List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3
CHAPTER 4
Application Development Tips and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Application design and development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Debugging your application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Adding a privacy module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Coding conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
File types and paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Snapshots and thumbnails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Application object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Camera object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Client object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NetConnection object (client-side) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
NetStream object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
SharedObject object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Stream object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Microphone object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Video object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
CHAPTER 5
Application Server Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Connecting through Flash Remoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Sample 1: Simple Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Sample 2: Sending Mail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Sample 3: Recordset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
APPENDIX
Flash Communication Server Management Tools . . . . . . . . . . . . . . . . . . . . 97
Using the Communication App inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using the NetConnection Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4 Contents
INTRODUCTION
About This Manual
Welcome to Macromedia Flash Communication Server MX!

The Flash Communication Server provides the technology to integrate streaming audio, video,
and data into a Macromedia Flash MX application using the Macromedia Real-Time Messaging
Protocol (RTMP), without requiring users to have anything but the current Macromedia Flash
Player. The ability to integrate communication into your Flash MX application supports the
development of a wide variety of multiuser collaboration applications, such as chat, webcasts,
whiteboards, and multiuser games. The Flash Communication Server also enables scalability, by
means of distributing your application’s processing among multiple servers, and extensibility, by
means of communicating with external sources such as application servers or databases.
Intended audience
This manual is a “how-to” book that takes you, the Flash Communication Server developer,
through the steps involved in setting up a development environment and creating Flash
Communication Server applications, including debugging and testing applications.
You should already be familiar with Flash MX authoring, ActionScript, and the Flash Player. You
should also have some familiarity with JavaScript (because it forms the basis of server-side
ActionScript), client-server models, and networking concepts.
About the Flash Communication Server documentation

The Flash Communication Server documentation is designed to be used in with the Flash MX
documentation, namely Using Flash MX and the Flash MX online ActionScript Dictionary.
This manual explains how to use the Flash MX authoring environment and the Flash
Communication Server application programming interface (API) to create communication
applications. To develop these applications, you need to write scripts that are contained in your
Flash FLA file and, in some cases, scripts that are stored with your application on the server. To do
so, you use the objects and methods provided in the Client-Side Communication ActionScript
API and Server-Side Communication ActionScript API.
This manual contains a number of sample applications that you can re-create. The samples start
simply and increase in complexity, introducing many of the client-side and server-side objects and
methods. By following these examples, you can begin writing Flash Communication Server
applications right away with Flash MX.
Other Flash Communication Server documentation describes client-side and server-side
ActionScript in more detail. All Flash Communication Server documents are available in PDF
format (viewable and printable with Adobe Acrobat Reader) and as HTML help. For document
locations, see Getting Started with Flash Communication Server.
About This Manual 5

Typographical conventions
The following typographical conventions are used in this manual:
• Code font indicates ActionScript statements, HTML tag and attribute names, and literal text
used in examples.
• Italic indicates placeholder elements in code or paths. For example, attachAudio(source)
means that you should specify your own value for source; \settings\myPrinter\ means that you
should specify your own location for myPrinter.
Additional resources
The Flash Communication Server documentation was written before the code in the product was
complete. Therefore, there may be discrepancies between the final implementation of the
product’s features and how they are documented in this manual. For a list of known discrepancies,
see the documentation update website (http://www.macromedia.com/go/
flashcom_documentation_update).
The Flash Communication Server Support Center (http://www.macromedia.com/go/
flashcom_support) is updated regularly with the latest information on Flash Communication
Server, as well as advice from expert users, advanced topics, examples, tips, and other updates.
6 Introduction
CHAPTER 1
About Flash Communication Server
Macromedia Flash Communication Server MX, the new platform for interactive personal
communication, integrates Macromedia Flash MX multimedia with live audio, video and data
streaming over networks, provides a system for storing recorded audio and video streams and
shared data objects, and enables the real-time sharing of synchronized distributed data among
multiple clients. This technology unites communication and applications, providing audio, video,
and data streaming between Macromedia Flash Player 6 clients.
The Flash Communication Server incorporates a number of features that support and enable the
creation of next-generation communication applications. In particular, the Flash Communication
Server:
• Provides an efficient, high-performance runtime for executing code, content and
communications.
• Integrates content, communications, and application interfaces into a common environment.
• Provides powerful and extensible object models for interactivity.
• Enables rapid application development through components and re-use.
• Enables the use of web and data services provided by application servers.
• Embraces connected and disconnected clients.
• Enables easy deployment on multiple platforms and devices.
Overview of Flash Communication Server architecture

The Flash Communication Server platform is made up of two parts: the server provides the
means of communication, and a Flash application (a SWF file that runs in Macromedia
Flash Player) provides the end user’s interface. You use the Flash MX authoring tool as your
development environment to create applications that use Flash Communication Server services.
Server-side scripting enables flexible control of shared state information and provides the logic for
mediating real-time interactions among multiple users.
The technology in Macromedia Flash Communication Server MX enables the capture of client
audio and video streams. When creating applications, it is your responsibility to comply with all
applicable laws, rules and regulations and to inform the user of privacy rights and your policies in
situations such as when the application transports audio or video data across insecure channels or
when video data is being recorded for publication. For an example of adding user notification to
your application, see “Adding a privacy module” on page 60.
7
Communications pass through the Flash Communication Server and are delivered to the client—
the Flash Player on a user’s computer—by means of the Macromedia Real-Time Messaging
Protocol (RTMP). When a Flash movie uses Flash Communication Server, the player connects
to the server, which provides a flow of information, called a network stream, to and from the
client. Other users can connect to the same server and receive messages, data updates, and
audio/video streams
Flash Player Flash Player

Server
Communications pass through the Flash Communication Server and are delivered to the Flash Player.
As the Flash Communication Server developer, you make this connection happen by working in
the Flash authoring environment to create a Flash movie that uses client-side ActionScript
commands. The Flash movie is the client element of your application. You can increase the
capabilities of your application by using server-side ActionScript. The client-side ActionScript
and the server-side ActionScript, combined, form the Flash Communication Server application
FLASH AUTHORING
Client-side .swf
component
Flash Communication
JAVASCRIPT EDITOR Server application
Server-side .asc
component
Flash authoring provides an easy way to create audio/visual applications in ActionScript.
8 Chapter 1
The Flash Communication Server lets you stream live media (audio, video, and data) or record
data to be played later, as illustrated below.
SERVER
NetStream object
Client publishes
Players
Live stream
SERVER
FLV NetStream object
Players
Recorded stream
About Flash Communication Server 9

To create audio/video applications, you must have audio/video capture devices (such as a camera
and microphone), Flash MX authoring software, and access to a Flash Communication Server.
You can also write applications that don’t require audio or video devices, as well as applications
that enable communication between Flash Communication Server and application servers or
external databases.
The rest of this chapter introduces the objects and files used in Flash Communication Server
applications, takes you through the steps involved in setting up your development environment,
and shows you how to create your first Flash Communication Server application.
10 Chapter 1
Flash Communication Server objects
As mentioned earlier, Flash Communication Server provides two application program interfaces
(APIs): a client-side API and a server-side API. The client-side API provides the following objects:
Camera, Microphone, NetConnection, NetStream, SharedObject, and Video. For more
information on using these objects, see the Client-Side Communication ActionScript Dictionary.
The server-side API provides the following objects: Application, Client, NetConnection,
SharedObject, and Stream. For more information on using these objects, see the Server-Side
Communication ActionScript Dictionary.
As you can see, some objects have the same name in both APIs, such as NetConnection. However,
a client-side object and a server-side object of the same name don’t provide the same functionality.
In addition, some client-side objects have server-side counterparts, but others do not. The
following sections briefly describe each client-side and server-side object, then explain how some
of them work together to allow client-server communications.
Client-side objects
These objects are used only in client-side ActionScript. For more information about these objects,
see the Client-Side Communication ActionScript Dictionary.
Camera object The client-side Camera object lets you capture video from a video camera
attached to the computer that is running the Flash Player. When used with the Flash
Communication Server, this object lets you transmit, display, and optionally record the video
being captured. With these capabilities, you can develop communication applications such as
videoconferencing, instant messaging with video, and so on.
You can also use a Camera object without a server (for example, to view a video feed from a
webcam attached to your local system).
Microphone object The client-side Microphone object lets you capture audio from a
microphone attached to the computer that is running the Flash Player. When used with the Flash
Communication Server, this object lets you transmit, play, and optionally record the audio being
captured. With these capabilities, you can develop communication applications such as instant
messaging with audio, recording presentations so others can replay them at a later date, and so on.
You can also use a Microphone object without a server—for example, to transmit sound from
your microphone through the speakers on your local system.
NetConnection object The client-side NetConnection object allows the Flash client to open a
TCP socket on the Flash Communication Server for continuous exchange of data using the Real-
Time Messaging Protocol (RTMP). You can also use the NetConnection object to connect to an
application server (see Chapter 5, “Connecting through Flash Remoting,” on page 85), but this
manual focuses on using the NetConnection object to communicate with the Flash
Communication Server.
NetStream object The client-side NetStream object opens a one-way streaming connection
between the Flash Player and the Flash Communication Server through a connection made
available by a client-side NetConnection object. A NetStream object is like a channel inside a
NetConnection; this channel can either publish audio, video, and data, using the
NetStream.publish method, or subscribe to a stream and receive data, using the
NetStream.play method. You can publish or play live (real-time) data and play previously
recorded data. Multiple clients can play a given stream, but a stream can have only one publisher
at a time. For information about the creation and storage of recorded streams on the server, see
“Recorded stream files” on page 68.

Local shared object Client-side local shared objects let you store information on a user’s
computer, such as the high score in a game, that can be used later by the same application or by a
different application running on that computer. For more information about local shared objects,
see “Understanding shared objects” on page 14.
Video object The client-side Video object lets you display streaming video on the Stage. To
display a video feed being played or captured through the use of a NetStream.play or
Camera.get command, place a Video object on the Stage and use the Video.attachVideo
method to attach the feed to the object.
To place a Video object on the Stage:
1 If the Library panel isn’t visible, select Window > Library to display it.
2 Add an embedded Video object to the library by clicking the Options menu at the upper right
of the Library panel and choosing New Video.
3 Drag the Video object to the Stage and use the Property inspector to give it a unique name.
Server-side objects
These objects are used only in server-side ActionScript. For more information about these objects,
see the Server-Side Communication ActionScript Dictionary.
Application object The server-side Application object contains information about a Flash
Communication Server application instance that lasts until the application instance is unloaded.
The Application object lets you accept and reject client connection attempts, register and
unregister classes and proxies, and create functions that are invoked when an application starts or
stops, or when a client connects or disconnects.
Client object The server-side Client object represents each user’s connection to a Flash
Communication Server application instance. The Client object can receive messages sent by a
client-side NetConnection.call command, and can invoke methods of the client-side
NetConnection object. You can use the properties of the Client object to determine the version,
platform, and IP address of each client. Using the Client object, you can also set individual read
and write permissions of various application resources such as Stream objects and SharedObject
objects. For more information, see “Implementing dynamic access control” on page 57.
NetConnection object The server-side NetConnection object lets you create a two-way
connection between a Flash Communication Server application instance and an application
server, another Flash Communication Server, or another Flash Communication Server
application instance on the same server. You can also use server-side NetConnection objects to
create more powerful applications; for example, you could get weather information from an
application server, or share an application load with other Flash Communication Servers or
application instances.
Using this object, you can connect to an application server for server-to-server interactions using
standard protocols (such as HTTP), or connect to another Flash Communication Server for
sharing audio, video, and data using the Macromedia Real-Time Messaging Protocol (RTMP).
You can use Macromedia Flash Remoting with the Flash Communication Server to communicate
with application servers such as Macromedia ColdFusion MX, .NET, and J2EE servers. For more
information, see the Flash Remoting site (http://www.macromedia.com/go/flashremoting).
12 Chapter 1
Remote shared object. Remote shared objects are created on the client but are also available to the
server. They let you share data in real-time between multiple clients, and also store data for later
retrieval by the same or different applications. For more information about client-side remote
shared objects, see “Understanding shared objects” on page 14.
SharedObject object. Server-side shared objects let you communicate with client-side shared
objects and with objects on other Flash Communication Servers. For more information about
server-side shared objects, see “Understanding shared objects” on page 14.
Stream object. The server-side Stream object lets you handle each stream in a Flash
Communication Server application. The Flash Communication Server automatically creates a
Stream object when the NetStream.play or NetStream.publish method is called in a client-
side script. You can also create a stream in server-side ActionScript by calling the Stream.get
method. A user can access multiple streams at the same time, and there can be many Stream
objects active at the same time.
Client-server object communications

The following “object pairs” represent the potential connections you can establish between client-
side and server-side objects. For example, when a client-side NetConnection object connects to
the server, a server-side Client object is created; this Client object can then call methods of its
NetConnection object counterpart.
The following table shows the client-side and server-side objects that are associated with each
other.
Client-side object Corresponding server-side object
my_nc (NetConnection object) my_client (Client object or application.clients

object)
my_ns (NetStream object) my_server_stream (Stream object)
my_so (remote shared object) my_server_so (server-side shared object)
In the following table, the client-side calls on the left invoke the server-side calls on the right.
Client-side call Server-side call
my_nc.connect application.onConnect
my_nc.close application.onDisconnect
my_nc.call("doThing", myCallbackFcn, 1, "foo") my_client.doThing(1, "foo")
my_so.send("doThing", 1, "foo") my_server_so.doThing(1, "foo")
In the following table, the server-side calls on the left invoke the client-side calls on the right.
Server-side call Client-side call
my_client.call ("doThing", myCallbackFcn, my_nc.doThing (1, "foo")

1, "foo")
my_server_stream.send ("doThing", 1, my_ns.doThing (1, "foo")

"foo")
my_server_so.send("doThing", 1, "foo") my_so.doThing(1, "foo")

Understanding shared objects
Shared objects are a means for sharing data among different clients, among different instances of
an application running on the Flash Communication Server, and across applications running on
multiple Flash Communication Servers. The Flash Communication Server supports three types
of shared objects—local, remote, and server-side. These objects are discussed briefly below. For
more information on working with shared objects, see “SharedObject object” on page 80.
Local shared objects

One way to use shared objects is for local storage and retrieval of data. Data is stored on the end-
user’s computer and may be accessed at different times by one or more Flash applications. Local
shared objects can also be non-persistent—that is, available only while the application is running.
Local shared objects don’t require a connection to the Flash Communication Server, and are not
discussed in detail in this manual. For information about where persistent local shared object data
is stored, see “Shared object files” on page 68. For more information about local shared objects,
see the SharedObject.getLocal entry in the Client-Side Communication ActionScript
Dictionary.
Remote shared objects

In client-side ActionScript, you can create and reference shared objects that are available to other
Flash Communication Server application instances running on the same or different clients. Like
local shared objects, these objects can persist on the local computer. However, they can also persist
on the server, so that any user who connects to the shared object has access to the same
information.
For example, you can open a remote shared object, such as a phone list, that is persistent on the
server. Whenever a client makes any changes to the shared object, the revised data is available to
all clients that are currently connected to the object or who later connect to it. If the object is also
persistent locally and a client changes the data while not connected to the server, the changes are
synchronized with the remote shared object the next time the client connects to the object.
Of all the types of shared objects, you will probably use remote shared objects most often in your
Flash Communication Server applications. Several of the samples in this manual use shared
objects for such tasks as sharing text (see “Sample 2: Shared Text” on page 35) and letting
multiple clients manipulate an object on the Stage at the same time (see “Sample 3: Shared Ball”
on page 37). For information about where persistent remote shared object data is stored, see
“Shared object files” on page 68. For more information about remote shared objects, see the
SharedObject.getRemote entry in the Client-Side Communication ActionScript Dictionary.
Server-side shared objects

As shown earlier (see “Client-server object communications” on page 13), you can use server-side
shared objects to communicate with client-side shared objects. In applications that implement
connectivity among multiple Flash Communication Servers, you can also use server-side shared
objects to share data between the servers. For more information about server-side shared objects,
see the SharedObject.get entry in the Server-Side Communication ActionScript Dictionary.
Applications and application instances

This section discusses where you must place application data that you want the server to find, and
also explains how and why to run application instances.
14 Chapter 1
The flashcom application directory
When your Flash application requires the Flash Communication Server, you must place your
application data where the server can locate it.
During installation, you choose either a Developer Install or a Production Install of the Flash
Communication Server. In both cases, if you don’t have a Web server installed, the default
directory is C:\Program files\Macromedia\Flash Communication Server
MX\flashcom\applications for both client-side application files—SWFs and HTMLs—and
server-side application files—ASC files, recorded stream (FLV) and remote shared object (FSO)
files, and your FLA source files.
• If you choose Developer Install, you can specify a different default directory during
installation, but Flash Communication Server will expect to find both client-side and server-
side files in subdirectories this directory. The advantage of choosing Developer Install is that
you can run the samples and test your applications from a single directory in the
\flashcom\applications directory that has the same name as your application. That is, for
convenience during development, client-side application files are stored in the same directory
with your server-side application files.
• If you choose Production Install, you can specify a different default directory for client-side
files and a different default directory for server-side files. Flash Communication Server will
know where to look for the files it needs. The advantage of choosing Production Install is that
your client-side application files can be accessible through a web server, while your server-side
application files will not be accessible to a user browsing your Web site.
For organizational purposes during your development work, it’s convenient to store all your client
and server application files (FLA, SWF, HTML, and ASC) in this subdirectory. When you deploy
your application, you can place your SWF and HTML files in any location. However, the
chat_App subdirectory must remain on the server, along with any ASC files used by the
application. The server-side files (your ASC, FLV, FSO, and FLA files) should not be in your web
root directory when you deploy the server and applications. Only your SWF and HTML files
should remain inside the web publishing directory.
If you chose Developer Install and then want to deploy your applications on the same machine,
you’ll want to separate client files from your server-side files. To do so, you can either reinstall the
server (choosing Production Install) and then relocate your files to the appropriate locations, or
you can change the configuration settings in the administration XML files as described in
Managing Flash Communication Server and then relocate your files to the appropriate locations.
In all cases, you must create a directory in the server-side directory that has the same name as the
application you connect to when issuing the NetConnection.connect command.
For example, suppose you have an application called chat_App:
NetConnection.connect("rtmp://myServer.myDomain.com/chat_app")
You must create a subdirectory named chat_App in your server-side flashcom application
directory. Suppose also that this application uses some server-side scripting stored in a file called
main.asc. You must place main.asc in this same directory.
Note: You must create a subdirectory that matches your application name even if you have no server-side script files
to place there. This is because Flash Communication Server stores any stream or shared object files created by your
application in subdirectories of this directory (see “File types and paths” on page 67). Also, the existence of this
directory tells the Flash Communication Server that the application is authorized and that users can connect to
instances of this application.

Using application instances
To distinguish among different instances of a single application, pass a value for instanceName to
your NetConnection.connect command. For example, you may want to give different groups of
people access to the same application without having them interact with each other. To do so, you
can open multiple chat rooms at the same time, as shown below.
my_nc.connect("rtmp://myServer.myDomain.com/chatApp/room_01")
my_nc.connect("rtmp://myServer.myDomain.com/chatApp/room_02")
Another reason to use application instances is to avoid collision of recorded streams or shared
objects that are created by the application. In the above example, for instance, any streams or
shared objects created by room_01 are distinct from those created by room_02, and vice versa,
even though both instances are running the same application, chat_App.
For example, although the support application in the following code creates two shared objects
named CustomerInfo, each instance of the support application has access only to its own
CustomerInfo object. Also, the data in CustomerInfo used by session1 is different from the data
in CustomerInfo used by session2.
// One instance of application "support"
first_nc = new NetConnection();
first_nc.connect("myserver.mydomain.com/support/session1");
first_so = SharedObject.getRemote("CustomerInfo", first_nc.URI, false);
first_so.connect(first_nc.URI);
// Another instance of application "support"

second_nc = new NetConnection();
second_nc.connect("myserver.mydomain.com/support/session2");
second_so = SharedObject.getRemote("CustomerInfo", second_nc.URI, false);
second_so.connect(second_nc.URI);
Many of the samples in this manual use the instance name room_01. However, you can use any
string for an instance name that makes sense in your application. For an example of dynamically
creating an instance name, see “Sample 5: Text Chat” on page 41.
For more information on using instance names, see the NetStream.publish entry in the Client-
Side Communication ActionScript Dictionary. For information on making remote shared objects
available to multiple applications, see the SharedObject.getRemote entry in the Client-Side
File types used by Flash Communication Server

In addition to the file types created and used by Flash MX (FLA, SWF, and SWD), Flash
Communication Server uses or creates the following file types:
• ASC—server-side script files that you write
• FLV and IDX—recorded streams and their associated index files
• FSO, SOL, and SOR—shared objects that are persistent on the client, the server, or both
You use a JavaScript editor to write ASC files, which you must place in your application directory;
this is illustrated in many of the sample applications in this manual. For more information about
creating ASC files, see “Setting up your development environment” on page 17. For information
on where Flash Communication Server stores stream and shared object files, see “File types and
paths” on page 67.
16 Chapter 1
Setting up your development environment
To write Flash Communication Server applications, you must install the Flash MX authoring
software, Flash Communication Server, and the latest Flash Player. If you want to write
applications that capture audio or video, you also need to install a microphone or camera.
Additionally, if your application requires server-side scripts for your Flash Communication Server
applications, you’ll need a UTF-8 JavaScript editor, such as Macromedia Dreamweaver MX. Each
of these elements of the development environment is discussed in this section.
Flash MX authoring software If you haven’t already installed Flash MX, see Getting Started with
Flash Communication Server.
Flash Communication Server software If you haven’t already installed the server, see Getting
Started with Flash Communication Server.
Flash Player Make sure that you are using the latest version of the Flash Player. To download
the latest version, go to the Macromedia Flash Player Download Center
(http://www.macromedia.com/go/getflashplayer).
Camera and microphone To install a camera or microphone, follow the instructions that
accompany your device. For a list of cameras that are known to be compatible with Flash
Communication Server, see the documentation on camera compatibility on the Macromedia
website (http://www.macromedia.com/go/camera_compatibility). Cameras that aren’t on this list
may be compatible with Flash Communication Server, but haven’t been tested by Macromedia.
Many cameras contain a built-in microphone. You can also install a separate microphone, or for
best results, a microphone/headset combination.
After you’ve installed your devices, you can specify which camera or microphone Flash should use
by default. Right-click (Windows) or Control-click (Macintosh) while any Flash MX movie is
playing, choose Settings from the context menu, click the Microphone or Camera panel, and
select your preferred device from the pop-up menu.
Using a JavaScript editor You can use any text editor to write server-side ActionScript code,
which you’ll store in files with an extension of .asc. You may prefer to use software specifically
designed for writing web-based applications, such as Macromedia Dreamweaver MX, which
offers syntax highlighting and code hinting for ASC files.
If you want to include non-ASCII text in your server-side scripts, such as double-byte characters
used in Asian languages, you must use an editor that supports UTF-8 encoding. The Flash
Communication Server requires UTF-8-encoded ASC files in order to pass double-byte
characters from one client to another. For more information on setting up Dreamweaver MX for
double-byte languages, see “Writing double-byte applications” on page 57.
Connecting to the server

To connect to a Flash Communication Server, you first start the service and then issue
new NetConnection and NetConnection.connect commands in your client-side script. These
tasks are discussed briefly in this section. For more detailed information, see the Client-Side

Starting the service
During server installation, you might have chosen to start the service automatically. If you did,
the service will be started whenever the server machine is started, and you don’t need to start it
manually. If you did not, you can start the server from the Windows Start menu: choose Programs
> Macromedia Flash Communication Server MX > Start Service. On Windows, to confirm that
the service is running, open the Task Manager and make sure both FlashCom.exe and
FlashComAdmin.e are listed in the Processes tab.
Opening a connection to the server

Open a new file in the Flash authoring environment, and then add the client-side ActionScript
commands to connect to the server.
To use ActionScript to connect to the server:
1 In a new Flash movie, begin opening a connection to the Flash Communication Server by
issuing the following command:
my_nc = new NetConnection();
2 Follow this command with a connect command:

my_nc.connect(targetURI);
In this basic syntax for NetConnection.connect (omitting optional parameters), targetURI

is the Uniform Resource Identifier (URI) of an application on the Flash Communication
Server that should run when the connection is made. To specify targetURI, use one of the
following formats (items in brackets are optional):
rtmp:[port]/appName[/instanceName] (acceptable if the movie and the Flash
Communication Server are on the same computer)
rtmp://host[:port]/appName[/instanceName]
Note that in both syntax examples for targetURI, you must specify rtmp (the Real-Time
Messaging Protocol) as the protocol for the connection. If you omit it, the Flash Player
assumes you want to make an HTTP connection to an application server, and your connection
will fail.
If the server is running on your local machine, you can use "localhost" as the host name in
the URI; this is often convenient during application development.
For example, the following code uses the new NetConnection constructor to create a new
connection object. Then, the object is connected to the server with the call to my_nc.connect.
// Makes a new connection object
// Connects to the instance named appInstance

// of the application named appName
// located on the Flash Communication Server
// that is running on myServer.myDomain.com
my_nc.connect("rtmp://myServer.myDomain.com/appName/appInstance");
18 Chapter 1
Writing your first application
The Flash Communication Server installation includes a sample application called doc_connect
that transmits text through the server between two clients. By viewing the source file and then
recreating the application yourself, you’ll learn how to write a simple Flash Communication
Server application. This example is included only to illustrate how easy it is to implement client-
server communication using Flash Communication Server. Before starting to write your own
programs, see Chapter 2, “About Flash Communication Server Applications,” on page 23.
Examining the sample connection application

The doc_connect application shows how to initialize a movie, connect to the server, and publish
and play a stream. It also explains where to save your sample files.
Note: These instructions assume that the service is running. For information on starting the service, see “Starting
the service” on page 18.
To view the source file:
Open the doc_connect.fla file located in the \Macromedia\Flash

MX\flashcom_help\help_collateral\doc_connect directory.
To see the sample in action:
1 Create a directory named doc_connect in the flashcom application directory (by default, the
application directory is Flash Communication Server MX\flashcom\applications).
2 Open the doc_connect.swf file located in the \Macromedia\Flash
MX\flashcom_help\help_collateral\doc_connect directory.
Note: If the application doesn’t seem to be working, make sure the service is running; see “Starting the service” on
page 18.
After allowing access to the audio and video devices, you see two images: the live stream from the
camera and the published stream sent back from the server.

Recreating the sample
This sample assumes you are using the Flash MX authoring environment on the computer that is
running the Flash Communication Server. If you aren’t, substitute your server URL for
“localhost” in the following steps. The sample also assumes that the service is running.
To create the user interface for this sample:
1 In the Flash authoring environment, select File > New to open a new file.
2 If the Library panel isn’t visible, select Window > Library to display it.
3 Add an embedded Video object to the library by clicking the Options menu at the upper right
of the Library panel and choosing New Video.
Options menu
4 Drag two embedded Video objects from the library onto the Stage and, in the Property
inspector, name them Live_video and Published_video.
5 Resize the Published_video video object to 200 x 150.
6 If you haven’t already done so, create a directory named doc_connect in your flashcom
application directory. Save the file as doc_connect.fla in this directory. (By default, the
application directory is Flash Communication Server MX\flashcom\applications).
To write the ActionScript for this sample:
1 Select the keyframe (frame 1) in the Timeline and open the Actions panel (Window >
Actions).
Note: While re-creating the sample, make sure all of the ActionScript is attached to this first keyframe, and not to
the objects you create on the Stage.
2 Get the default camera and attach it to the Live_video embedded video object.
client_cam = Camera.get();
Live_video.attachVideo(client_cam);
20 Chapter 1
3 Create a connection function that connects to the Flash Communication Server, displays a
trace message indicating whether the connection was successful, and opens and instance of the
doc_connect application named room_01. Remember, you must specify the Real-Time
Messaging Protocol, rtmp.
function doConnect() {
client_nc = new netConnection();

client_nc.onStatus = function(info) {
trace("Level: " + info.level + " Code: " + info.code);
}
client_nc.connect("rtmp://localhost/doc_connect/room_01");
}
Note: If your SWF is on the same computer that is running the Flash Communication Server, you can use
rtmp:/doc_connect/test as a shortcut version of rtmp://localhost/doc_connect/test. This usage indicates a
relative path and lets you move the files to a different server without changing the code. Also, remember that if
you aren’t using the Flash MX authoring environment on the computer that is running the Flash Communication
Server, substitute your server URL for “localhost”.
4 Create a function to publish the video by creating a network stream out_ns, attaching the
camera to that stream, and then publishing the stream as myTestStream.
function publishMe() {
out_ns = new netStream(_root.client_nc);

out_ns.attachVideo(client_cam);
out_ns.publish("myTestStream");
}
Note: The statement out_ns.publish("myTestStream") omits the optional parameter howToPublish.
When this parameter is missing, the server automatically publishes the stream as live (that is, the stream is not
recorded while it is being published).
5 Create a function to play the published stream by creating a second network stream in_ns,
attaching the contents of that stream to the Published_video video object, and then playing
the stream named myTestStream that is being published by the server.
function playMe() {
in_ns = new netStream(_root.client_nc);

Published_video.attachVideo(in_ns);
in_ns.play("myTestStream");
6 Write the commands to call the functions you just created.

// Connect to the server
doConnect();
// Publish the live stream

publishMe();
// Play back the stream from the server

playMe();
7 Save the file.

To test your sample application:
1 Choose File > Publish Settings, select Flash and HTML, click Publish, and then click OK.
2 Choose Control > Test movie.
You see two video windows on the Stage, each displaying the same image.
3 To see how the movie looks in a browser, choose File > Publish Preview > Default, or press
Control+F12 (Windows) or Command+F12 (Macintosh).
Congratulations, you’ve just created and tested your first Flash Communication Server
application! This sample, of course, is for instructional purposes, and has both streams displayed
in a single movie. In a real application, one movie would publish the video feed and another
movie would play it.
This sample was included to show how just a few lines of code can implement client-server
communications using Flash Communication Server. Before you begin writing your own scripts,
be sure to read through the conceptual information provided in Chapter 2, “About Flash
Communication Server Applications,” on page 23, which provides an important overview of the
objects available to you as a Flash Communication Server developer.
22 Chapter 1
CHAPTER 2
About Flash Communication Server
Applications
With a few lines of code, your Macromedia Flash MX application (SWF) can communicate with
another client through the Macromedia Flash Communication Server MX. Using object-oriented
programming techniques and sound programming practices, you can write simple ActionScript
code to get started right away.
This chapter explains some ideas behind Macromedia Flash Communication Server MX and
describes the types of files you’ll generate. An overview of the ActionScript objects specific to
Flash Communication Server is also described here.
About Flash Communication Server services

You should be familiar with writing the instructions for a Flash application in a FLA file and
publishing it as a SWF file. When you run the SWF file, the Flash Player processes the
instructions. If these instructions do not include any calls to a Flash Communication Server, the
player relies on all of the technology within the player itself to execute each step. As soon as you
make a Flash Communication Server call in your ActionScript, however, the player sends that
request to the server.
After you use new NetConnection to create an instance of the NetConnection object, the first
call you make to the server is NetConnection.connect, which tells the player to connect to an
application on the server. The Flash Communication Server requires the use of the Real-Time
Messaging Protocol (RTMP):
my_nc.connect("rtmp://myFlashComServer/myAppName/instanceName");
Once your Flash application issues this command (and succeeds in connecting to the server), it
has become a client-server application, and the instance of your Flash application running in the
player is referred to as the client.
Common client-server workflows

After the connection is established, the services provided by the server depend, in part, on what
the client expects. Four common scenarios are described below.
23
Passing data between clients In Chapter 1, the sample connection application (see “Writing
your first application” on page 19) connected to the server, opened a stream to publish some
video, and opened another stream to receive the data (play back the video). The only thing the
server was expected to do was to pass the video data through and back to the client. (In a real-life
scenario, of course, the video data would pass through the server to a different client at another
location.)
Client 1 Client 2
Server
The Flash Communication Server provides a channel of communication for clients.
Storing data for delivery to clients The Flash Communication Server can store information that
is useful to multiple clients—for example, a recorded video or the high score in a multiuser game.
Many samples in this manual rely on the server to store information. (For more information on
where data files are stored, see “File types used by Flash Communication Server” on page 16.)
Client 1 Client 2
Server
The Flash Communication Server stores information that is useful to one or more clients.
24 Chapter 2
Tracking client information You can use server-side ActionScript to collect and display
information regarding clients, transform data, moderate the communication, test conditions,
notify using e-mail and other means, and provide many other services. For example, later you’ll
work through samples that not only rely on the server to route information, but also expect the
server to keep track of client information. When you expect the server to provide some
application logic and return a result, you must provide the instructions in the form of server-side
ActionScript commands.
Client 1 Client 2
Server
The Flash Communication Server processes information and sends it back to the client.
Connecting to external sources You can also use server-side ActionScript to develop
applications that interact with other servers; for example, your application might access a
database, and application server, or another Flash Communication Server. In this way, server-side
ActionScript can be used to add dynamic content to your application.
Client 1 Client 2
The Flash Communication Server communicates with other services.
The Flash Communication Server design model

In traditional client-server architecture, the client code provides the presentation layer, and the
server code enhances and organizes the experience using behind-the-scenes actions. For example,
server-side scripts in traditional web applications are most frequently used for some kind of
transaction; the client makes a request, the server does a database lookup or some resource-based
calculation, and then returns a result to the client.
About Flash Communication Server Applications 25

While you can use the Flash Communication Server server-side scripting language to implement
transactions, either internally or by communicating with an external server or data source, the
core use of Flash Communication Server is handling interactions—coordinating the actions of
multiple, connected applications and transmitting server-side data.
The rest of this section discusses the Flash Communication Server in the context of managing
client-server and client-client interactions. You should already be familiar with the workflow of
ActionScript as described in Using Flash MX. If not, see “Understanding the ActionScript
Language” in Using Flash MX.
Flash Communication Server workflow

This manual uses Flash Communication Server sample applications to demonstrate all the steps
involved in writing, testing, and deploying Flash Communication Server applications. In general,
however, the workflow is simple: it consists of adding client-side ActionScript to your Flash
application, using server-side ActionScript if necessary, and publishing your files in your flashcom
application directory. (By default, Flash MX automatically generates an HTML wrapper file
when you select File > Publish.)
SWF FILE
.swf Flash MX logic
ActionScript
<HTML>
.swf
</HTML>
.swf
HTML FILE
Web server
directory
.html HTML
HTML wrapper
ASC FILE
.asc
.asc Server logic
Server-side .flv
ActionScript Flash Com
application directory
26 Chapter 2
When the user runs your Flash SWF file and the SWF file connects to the server, the server loads
the application and creates the application instance if it isn’t already running. The server accepts
the connection, creates a new Client object to represent the client application on the server, and
executes any server-side scripts that you have provided. The client also does its work, initiating
streams, sharing objects, and so on. The following sections describe this sequence of events in
more detail.
Note: Only the client application can initiate a communication session, and only the server can shut down an
application. Both the client and the server send and receive status messages, open and close streams, save and
share data, and end the network connection.
Application workflow
When the client connects to the server, the server calls onAppStart if the application instance
isn’t already running. Next, the server-side onConnect method is invoked with a newly created
Client object. The logic in this method determines whether to accept or reject the connection.
Back on the client side, the onStatus method is called to report whether the connection was
accepted or rejected. When the client closes the connection, the server-side onDisconnect
method is called. When the application is unloaded, onAppStop is invoked.
CLIENT FLOW SERVER FLOW
onAppStart
connect new Client object onConnect
onStatus acceptConnection
close onDisconnect
Application is
unloaded
onAppStop
Connection flow

After a successful connection, the client makes a call on the connection. If the client needs a result
returned, the client provides a callback object to hold the result. On the server, the method
corresponding to the client call is invoked; and a result is returned to the client. The client has an
onResult handler that is called on the callback object passed in.
CLIENT SERVER
call("doThis",
"doThis",a,b
callback_obj,a,b)
clientObj.doThis(a,b)
onResult resultObj
Call flow from client to server, with result passed back to client
Conversely, if a server makes a call to the client, it can provide a callback object. The client should
contain a method corresponding to the one called by the server code. Again, the client can return
a result, and the server’s onResult handler is called on the callback object sent to the client.
CLIENT SERVER
client.call("doThis",
"doThis",a,b
callback_obj,a,b)
netConnection.doThis(a,b)
resultObj resultObj.onResult
Call flow from server to client, with result passed back to server
28 Chapter 2
Finally, here’s an overview of the remote shared object flow. A Flash client movie subscribes to a
remote shared object by issuing a SharedObject.getRemote command, and provides a
SharedObject.onSync method with it. The client then connects the remote shared object to the
NetConnection object by issuing a SharedObject.connect command. The server sends out a
synchronization message for the shared object, but no method on the server side is invoked. This
synchronization message causes the SharedObject.onSync method on the client to be called.
When the client, the server, or any other movie instance makes a change to the shared object, the
server again sends out a synchronization message for the shared object. Again, no server method is
called, and the synchronization message from the server causes the SharedObject.onSync
method on each client to be called.
CLIENT 1 FLOW SERVER FLOW CLIENT 2 FLOW
getRemote("obj1") getRemote("obj1")
connect connect
onSync Sync onSync

"clear" (Initialize data) "clear"
obj1.data.x=4
onSync Sync onSync

"success" (Update data) "change"
Shared object flow
Designing Flash Communication Server applications

Now that you have a basic understanding of the structure and capabilities of Flash
Communication Server, you need to consider how to design your own applications to best take
advantage of client-side and server-side scripting.
When designing a Flash Communication Server application, determine what capabilities it will
have, what it requires of the server, and whether the application’s capabilities call only for client-
side ActionScript or for server-side ActionScript as well. If you want the server to act as a conduit
for your audio, video, and text streams, you might need only client-side ActionScript; if you want
the server to process data, you’ll need to write server-side ActionScript as well.
Although building client-server applications may seem complicated, in many cases it is easier to
write a small amount of server-side code than it is to handle everything in client-side code. (Of
course, in some cases, only server-side code can accomplish certain tasks.) For example, server-
side scripts can act as a “gatekeeper” for your application; by setting certain data on the server, you
can eliminate race conditions (multiple clients attempting to perform the same task at the same
time) and may eliminate the need for client-side code to handle conflict resolution.

When designing your application, note the functionality used on both the client and the server.
For a description of how to use the client-side and server-side objects to fulfill the requirements
on both sides, see the Client-Side Communication ActionScript Dictionary and the Server-Side
In general, when you write your ActionScript code, you divide it as follows:
• On the client side, write code for connecting, streaming data, getting and setting shared object
data, getting status information, and disconnecting.
• On the server side, write code for listening for when an application starts, accepting a
connection, providing methods to be invoked by clients, getting and setting shared object data,
getting status information, and listening for when an application stops and a connection ends.
In more advanced applications, you might also be connecting to external databases, application
servers, or other Flash Communication Servers.
For a simple illustration of using client-side and server-side ActionScript in your application, see
“Sample 4: Hello Server” on page 38. For more detailed suggestions on how to design and
implement your Flash Communication Server applications, see Chapter 4, “Application
Development Tips and Tricks,” on page 51.
30 Chapter 2
CHAPTER 3
Sample Applications
This chapter provides examples of a number of Macromedia Flash Communication Server MX

programming techniques, and illustrates how to use many of the Flash Communication Server
objects. These samples are different from the ones provided in the flashcom application directory,
although certain concepts are illustrated in both sets of samples. In general, the samples in this
chapter are simpler than a full-blown application would be; they have been designed specifically
to illustrate certain features in context.
About the samples

The samples in this chapter are progressive: skills shown in later samples rely on information you
gain from working with the prior samples. If you’re not sure how to proceed with a step, check an
earlier sample. You can read more about the commands used here in the Client-Side
Communication ActionScript Dictionary and the Server-Side Communication ActionScript
Dictionary. For the core ActionScript commands, see the online ActionScript Dictionary in
Macromedia Flash MX.
Each sample section provides an overview of the sample, a description of the user experience, a
procedure for creating the user interface and the ActionScript code, and a suggested methodology
for testing your application.
Files associated with the samples (FLA, SWF, HTML, and ASC) are located in subdirectories of
the \Macromedia\Flash MX\flashcom_help\help_collateral directory.
Creating your working environment

This section explains what you need to know before trying to re-create any of the samples.
The samples assume that the Flash Communication Server is
Make sure the server is running.
running. For more information, see “Starting the service” on page 18.
Specifying the server URI. The samples assume you’re using the Flash MX authoring environment
on the same computer that is running the Flash Communication Server. If that isn’t the case, add
your server name to all the connect commands in the samples. For example, if your server is
running at myServer.myDomain.com, change a line like this:
new_nc.connect("rtmp:/doc_record/room_01");
to this:
new_nc.connect("rtmp://myServer.myDomain.com/doc_record/room_01");
Note: Be sure you use two slashes (//) after rtmp: in the revised code. The use of a single slash is supported only
when the SWF application and the Flash Communication Server are running on the same machine.
Sample Applications 31
You should have Flash MX configured to publish both SWF and
Specifying publishing formats.
HTML files. To specify formats to be created during publishing, choose File > Publish Settings in
the Flash MX authoring environment.
Writing client-side ActionScript code. Unless otherwise noted, your client-side ActionScript code
should be attached to a layer on the first keyframe of your FLA file, not to individual objects.
Writing server-side ActionScript code. For the samples that use server-side ActionScript code,
your main.asc file should be written in a JavaScript editor, such as Macromedia Dreamweaver
MX. For more information on appropriate JavaScript editors, see “Setting up your development
environment” on page 17. Also, remember that server-side code is case-sensitive.
Initializing your client-side code. Add the following code as the first two lines in each sample as
you re-create it (these lines are in each sample FLA but are not included in the steps for re-
creating the sample):
stop();
#include "netdebug.as"
The first line simply ensures that movies stop running before the sample starts. The second line
enables the use of the NetConnection debugger, which lets you trace and diagnose details about
the streams and shared objects your application is using. For more information on the debugger,
see “Using the NetConnection Debugger” on page 105.
Acknowledging the user’s right to privacy. Before recording or broadcasting anyone’s image or
voice, it’s important to inform that person of your intention and to gain their consent or
agreement. In the samples that illustrate how to record or broadcast audio or video, you’ll see
instructions to add a text box that informs users they are being recorded or broadcasted and
gives them the opportunity to exit the application. For a more robust means of letting users
decide whether they want to be recorded or broadcasted, or not, see “Adding a privacy module”
on page 60.
Monitoring running applications. If you have server administration privileges, you can view details
about an application while you are testing it, such as log messages it is generating, values of shared
objects, and so on. To do so, open the Communication App inspector in Flash MX (Window >
Communication App Inspector), connect to the Flash Communication Server, select the
application instance you want to monitor, and choose View Detail. For more information, see
“Using the Communication App inspector” on page 97.
Sample 1: Recording a Stream

This recording sample records a video stream. When the user clicks the Play button, the recorded
data is streamed back to the Flash movie.
About the sample

The user opens the doc_record.html file. After the user grants access to its video device, the live
output appears in the larger video area called Live_video. When the user clicks the Record
button, the live camera’s stream is sent for recording on the Flash Communication Server. When
the user clicks the Stop button, the server stops recording. When the user clicks the Play button,
the server sends the recorded stream back to the application, and the recorded stream plays in the
smaller video area.
32 Chapter 3
Re-creating the sample
The doc_record.fla file provides the ActionScript for getting a camera, attaching it to a Video
object, creating a network connection to the server, recording the camera data on an outgoing
stream to the server, and then playing that recorded stream in a second Video object.
When you record a stream in a Flash application, the server creates files with the extensions .flv
and .idx. For more information, see “Recorded stream files” on page 68.
See “Creating your working environment” on page 31 before you start to re-create the sample.
1 In the Flash MX authoring environment, select File > New to open a new file.
2 To add a Video object to your library, open the Library panel (Window > Library) and add an
embedded Video object by selecting New Video from the library’s Options menu.
3 Drag two embedded Video objects from the library onto the Stage, and give them the instance
names Live_video and Replay_video.
4 To add buttons to your movie, open the Components panel by selecting Window >
Components.
5 To add the button for recording, drag a push button from the Components panel onto the
Stage, placing it below the Live_video video object. In the Property inspector, give it the
instance name Record_btn, the label Record, and the click handler doRecord.
6 To add the button for playing, repeat the previous step to create a push button with the
instance name Play_btn, the label Play, and the click handler doPlay. Place this button
beneath the Replay_video video object.
7 To add the privacy message, select the Text tool and draw a text box. In the Property inspector,
select Static Text for the type of text box. Type (or copy and paste) text such as the following
text into the text box: Your image will be recorded or broadcasted and could be published at
a later date. If you don’t approve, please exit this application.
Note: Please note that this text is provided merely as an example, and the precise wording of the text that you
use will be dictated by the nature of your application and/or service and any privacy, legal, or other issues raised
by your application and/or service.
8 Create a directory named doc_record in your flashcom application directory, and save the file
as doc_record.fla in this directory.
To write the client-side ActionScript for this sample:
1 Select the keyframe in the Timeline and open the Actions panel (Window > Actions).
2 In the Actions panel, stop the progress of the movie.
stop();
3 Get and attach a camera.

// Attach the video device output from client_cam
// to the Live_video video clip
client_cam = Camera.get();
Live_video.attachVideo(client_cam);
4 In the initStreams function, make a connection to the server. Create the output stream for
sending the video data to the server, and the input stream for the data coming back from the
server. Then attach the input stream to the Replay_video video clip.
function initStreams() {
// Make a connection to the application on the server

client_nc = new NetConnection();
// Note that this call includes the protocol, rtmp, the

// app name, doc_record, and the room, room_01
client_nc.connect("rtmp:/doc_record/room_01");
// Handle status message

}
// Create output stream

out_ns = new NetStream(client_nc);
// Create input stream

in_ns = new NetStream(client_nc);
Replay_video.attachVideo(in_ns);
// Connect to server and set up streams

initStreams();
5 Create the event handler for the Record button. If the user selected the button when the label
was Record, then attach video data from the camera to the output stream and publish it. If the
button label is Stop, close the stream.
function doRecord() {
if (Record_btn.getLabel() == "Record") {
// Start publishing the camera output as a recorded stream

out_ns.attachVideo(Camera.get());
out_ns.publish("my_recorded_stream", "record");
// Don’t allow the user to play when recording

Play_btn.setEnabled(false);
// Change the button label

Record_btn.setLabel("Stop");
} else if (Record_btn.getLabel() == "Stop") {
// Close output stream

out_ns.close();
// Now that you’re finished recording, allow the user to play

Play_btn.setEnabled(true);
// Change the button label

Record_btn.setLabel("Record");
}
}
34 Chapter 3
6 Create the event handler for the Play button that plays the stream recorded on the server.
function doPlay() {
in_ns.play("my_recorded_stream");
1 In the Flash MX authoring environment, after you have saved your work, publish it by
selecting File > Publish.
2 Open the SWF file in the application directory or, in the Flash MX authoring environment,
choose Control > Test Movie.
Sample 2: Shared Text

This sample allows users to share text. Any user can update the text on the stage, and other users
can see it immediately updated on their own stages.
About the sample

User 1 opens the doc_text.html file and is able to type text in the text box. User 2 opens the same
movie and automatically connects to the same shared object. User 2 can see the text as user 1
types it. When user 2 edits the text, user 1 can view the changes as they occur.

The doc_text.fla file uses only a few lines of code to connect to the Flash Communication Server,
create and connect to a remote shared object, and update the shared object on the Stage that all
connected clients are viewing.
This sample introduces the idea of shared objects (for more information, see the Client-Side
Communication ActionScript Dictionary). In this sample, you call
SharedObject.getRemote("sharedtext", new_nc.uri, false). These shared objects are
synchronized with the server over an RTMP connection. Shared objects consist of name-value
pairs and can be updated by any client connected to the application and the shared object.
2 From the toolbox, select the Text tool and draw a text box.
3 In the Property inspector (Window > Properties), select Input Text for the type of text box, and
give it the instance name TypingStage.
4 Create a directory named doc_text in your flashcom application directory, and save the file as
doc_text.fla in this directory.
2 Open a connection to the server.
// Open connection to server
client_nc.connect("rtmp:/doc_text/room_01");
3 Handle the messages coming from the server.
}
4 Initialize the typing stage.

TypingStage.text = "";
5 Get a remote shared object to hold the text data from the client.
// Create a remote shared object. client_nc.uri is the URI of the
// NetConnection the shared object will use to connect to the
// server.
text_so = SharedObject.getRemote("sharedtext", client_nc.uri, false);
6 When you get a shared object, make sure you connect to it.
// The following is very important, nothing happens otherwise
text_so.connect(client_nc);
7 Create an onSync callback function to handle the text message.
// Each time something changes in the shared object, the server
// sends out a synchronization message. This onSync handler
// updates the movie based on the information.
text_so.onSync = function(list) {
// Update the text area in the typing stage with the latest
// text from the shared object. The ’for’ loop condition searches
// through the list of changes, and the ’if’ condition ensures
// that we apply the relevant change only if someone other than
// this client has changed the value.
for (var i = 0; i < list.length; i++)
if (list[i].name == "textValue" && list[i].code != "success")
{
TypingStage.text = text_so.data.textValue;
break;
}
};
8 When the text in the typing stage changes, update the shared object with the new text.
// Update the shared object every time the user types in new text
TypingStage.onChanged = function()
{
text_so.data.textValue = TypingStage.text;
};
2 Open two instances of the SWF file in the application directory.
3 Type in one text box to see the other immediately updated.
36 Chapter 3
Sample 3: Shared Ball
This sample allows users to move a ball around the screen and to watch while other participants
move the ball around.
About the sample

The previous sample shared text, but you can share graphics as well. This sample allows two users
to share the same ball on the Stage. When a user opens the doc_sharedball.htm file, there is a ball
on the SWF Stage. When any user moves the ball, all other connected users see it move.

The doc_sharedball.fla provides the ActionScript for creating a remote shared object that
synchronizes and updates the ball position for each user.
2 From the toolbox, select the Circle tool and draw a circle. With the circle still selected, convert
it to a movie clip by selecting Insert > Convert to Symbol, and name it ball. In the Property
inspector (Window > Properties), give it the instance name SharedBall_mc.
3 Create a directory named doc_sharedball in your flashcom application directory, and save the
file as doc_sharedball.fla in this directory.
stop();
3 Create a new network connection to connect to the server and handle any status messages with
the onStatus function.
// Create a connection
// Show connection status in output window
};
// Connect to the application

client_nc.connect("rtmp:/doc_sharedball/room_01");
4 Create a remote shared object to hold the x/y coordinates of the ball.
// Create a remote shared object
ball_so = SharedObject.getRemote("position", client_nc.uri, false);
// Update ball position when another participant moves the ball

ball_so.onSync = function(list) {
SharedBall_mc._x = ball_so.data.x;
SharedBall_mc._y = ball_so.data.y;
};
5 When you get a shared object, make sure you connect it to the NetConnection object.
// Connect to the shared object
ball_so.connect(client_nc);
6 Create the function that updates the shared object data with the position of the ball.
// Manipulate the ball
SharedBall_mc.onPress = function() {
this.onMouseMove = function() {
ball_so.data.x = this._x = _root._xmouse;
ball_so.data.y = this._y = _root._ymouse;
// Constrain the ball to the stage

if (SharedBall_mc._x>=Stage.width) {
SharedBall_mc._x = Stage.width - 50;
}
if (SharedBall_mc._x<=0) {
SharedBall_mc._x = 50;
}
if (SharedBall_mc._y>=Stage.height) {
SharedBall_mc._y = Stage.height - 50;
}
if (SharedBall_mc._y<=0) {
SharedBall_mc._y = 50;
}
};
};
7 When the user releases the ball, remove the hold on it.
// Release control of the ball
SharedBall_mc.onRelease = SharedBall_mc.onReleaseOutside=function () {
delete this.onMouseMove;
};
2 Open two instances of the SWF file in the application directory.
3 Move the ball in one instance to see the other immediately updated.
Sample 4: Hello Server

This sample is the first to use server-side ActionScript. In it, you write your client-side
ActionScript in Macromedia Flash MX. Then, you write a corresponding function in server-side
ActionScript that you store in a main.asc file. First, however, you begin with the user interface.
About the sample

The user opens the doc_hello.swf file, enters a name, and gets a message back from the server that
includes the user’s name.

The doc_hello.fla file provides the ActionScript for sending information from the server to the
client.
38 Chapter 3
2 From the toolbox, select the Text tool and draw a text box. In the Property inspector (Window
> Properties), select Input Text for the type of text box and give it the instance name User.
3 Add a dynamic text box for a debug window by selecting the Text tool and drawing another
text box. In the Property inspector, select Dynamic Text for the type of text box, and give it the
instance name Message.
4 To add the button for connecting to the server, open the Components panel (Window >
Components) and drag a push button onto the Stage. In the Property inspector, give it the
instance name Connect_btn, the label Connect, and the click handler doConnect.
5 Create a directory named doc_hello in your flashcom application directory, and save the file as
doc_hello.fla in this directory.
stop();
3 Open a connection and handle any status message.

// Open connection to the server

}
4 Create the event handler for the Connect button. If the user selected the button when the label
was Connect, then connect to the server. If the button label is Disconnect, close the
connection.
// Event handler for Connect_Btn
// If user wants to connect...

if (Connect_btn.getLabel() == "Connect") {
// Connect to the chat application

client_nc.connect("rtmp:/doc_hello/room_01", User.text);
// Update button label

Connect_btn.setLabel("Disconnect");
// If user wants to disconnect...

} else if (Connect_btn.getLabel() == "Disconnect") {
// Close connection
client_nc.close();
// Reset button label

Connect_btn.setLabel("Connect");
// Reset the text fields

user.text = "";
message.text = "";
}
}
5 Write the function the server will call to return the message to the client.
// Callback function server calls to send message back to
// this client.
client_nc.msgFromSrvr = function(msg) {
var msg;
_root.Message.text = msg;
40 Chapter 3
To write the server-side ActionScript for this sample:
1 Create a new file using your server-side ActionScript editor, and write an event handler for
when the user connects. In it, you’ll receive the name passed in by the client, accept the client
connection, create a message that uses the client’s name, and call the client msgFromSrvr
function to return the message.
application.onConnect = function(newClient, name) {
// Give this new client the same name as the user name
newClient.name=name;
// Accept the new client’s connection

application.acceptConnection(newClient);
// Create a customized "Hello [client]" message

// that the server will send to the client
var msg = "Hello! You are connected as: " + newClient.name;
// Print out status message in the application console

trace("Sending this message: " + msg);
// Call the client function, message, and pass it the msg

newClient.call("msgFromSrvr", false, msg);
}
2 Save the file as main.asc in a doc_hello directory under the flashcom applications directory.
Note: Save this main.asc file where you’ve chosen to store your server-side application files. For example, if you
chose Developer Install during installation, save this file to the same directory where you’ve stored the client-side
SWF file and its source FLA file. If you chose Production Install and you have a Web server, the Flash
Communication Server will look for your client-side files under \flashcom\applications in your Web server's root
directory and will look for your server-side application files (including this main.asc file) under \applications in the
directory you specified during installation. The <AppsDir> tag in the Vhost.xml server configuration file contains
the location of your flashcom application directory. For more information see Chapter 1, “The flashcom
application directory,” on page 15.
2 Open the SWF file in the application directory.
3 Overwrite the text in the login box by typing your name, then click Connect. You’ll see a
message like this one:
Hello! You are connected as: [your name]
Sample 5: Text Chat

In the Shared Text example (see “Sample 2: Shared Text” on page 35), you created a remote
shared object that enabled a user to view another user’s typing in real time, letter by letter. In this
next sample, you’ll create a different kind of shared object that sends whole messages on
command. You’ll also add several elements to make the text chat application more versatile,
including fields for logging in, typing in a chat room name, and viewing the list of current
participants.
About the sample
In a chat room, you want to view current users dynamically. When users log in to a room, the list
should be updated; when users log off, they should be removed from the list. It’s best to do this
processing work on the server, because keeping data centrally on the server means that any client
can come and go, and the data will always be accurate and available.
In addition, in this example, the server doesn’t simply hand off the text from one client to
another, it actually makes changes to the message by adding the name of the user who typed it.
Because you expect the server to provide this functionality, you need to write some server-side
ActionScript to handle this work.
Finally, this example also illustrates how to dynamically add an instance name to a
NetConnection.connect command based on data entered by the user.

The doc_textchat.fla file provides the ActionScript for letting multiple users share text in
real time.
2 From the toolbox, select the Text tool and draw two text boxes. In the Property inspector
(Window > Properties), select Input Text for the type of text box, and give one the instance
name User, and the other, Room.
3 From the toolbox, select the Text tool and draw another text box. In the Property inspector,
select Input Text for the type of text box, and give it the instance name Message.
4 From the toolbox, select the Text tool and draw a fourth text box. In the Property inspector,
select Dynamic Text for the type of text box, and give it the instance name History.
5 To add a place where users are listed, open the Components panel (Windows > Components),
drag the List Box component onto the Stage, and give it the instance name People.
6 To add the button for connecting to the server, drag a push button from the Components
panel onto the Stage. In the Property inspector, give it the instance name Connect_btn, the
label Connect, and the click handler doConnect.
7 To add the button for sending messages, drag a push button from the Components panel onto
the Stage. In the Property inspector, give it the instance name Send_btn, the label Send, and
the click handler doSend.
8 Create a directory named doc_textchat in your flashcom application directory, and save the file
as doc_textchat.fla in this directory.
stop();
42 Chapter 3
3 Provide a value for the maximum scrolling of the History text box component.
// Set maximum scroll
History.maxscroll = 1000;
4 Prevent the user from sending until after the user has connected to the server.
// Don’t allow the user to send until after connection
_root.Send_btn.setEnabled(false);
5 Create a new network connection.
// Open a connection to the server
6 Provide an onStatus function to handle any status messages.
// If connection is closed, clear the History and the list
if (info.description == "NetConnection.Connect.Closed") {
History.text = "";
_root.People.removeAll();
}
}
7 Create the event handler for the Connect button. If the user selected the button when the label
was Connect, then connect to the server and update the buttons.
if (Connect_btn.getLabel() == "Connect") {
// Connect to the chat application.

// The second parameter, _root.Room.text,
// is the application instance.
_root.client_nc.connect("rtmp:/doc_textchat/" + _root.Room.text,
_root.User.text);
// Update button label

Connect_btn.setLabel("Disconnect");
// Enable send button

_root.Send_btn.setEnabled(true);
8 In the same doConnect function, create a remote shared object and connect to it.
// Create a remote shared object to keep track
// of the users. The value client_nc.uri is the URI of the
// NetConnection the shared object will use to connect to the
// server. I.e., the one just created.
users_so = SharedObject.getRemote("users_so", _root.client_nc.uri,
false);
// Attach the shared object to client_nc

users_so.connect(_root.client_nc);
9 In the same doConnect function, create the onSync method to handle the change in users.
// When the list of users_so is updated, refresh the
// People list box.
users_so.onSync = function(userList) {
_root.People.removeAll();
for ( var i in users_so.data) {

if (users_so.data[i] != null) {
_root.People.addItem(users_so.data[i]);
}
}
// Sort alphabetically, because order returned

// is not guaranteed to be consistent.
_root.People.sortItemsBy("label", "ASC");
}
10 Provide a callback function to be called by the server.
// Update the shared object with the message.
users_so.msgFromSrvr = function(msg) {
_root.History.text += msg;
_root.History.scroll = _root.History.maxscroll;
historyScroll.setScrollTarget(history);
historyScroll.setScrollPosition(_root.History.maxscroll);
}
}
11 If the label on the Connect button is Disconnect, then close the connection and reset the
buttons.
else if (Connect_btn.getLabel() == "Disconnect") {
// Close connection
_root.client_nc.close();
// Don’t allow the user to send when not connected

_root.Send_btn.setEnabled(false);
// Rest button label

Connect_btn.setLabel("Connect");
}
} // doConnect function ends here
12 Create an event handler for when the user selects Send. In this function, if there’s any text in
the Message input text box, call the server function, msgFromClient, and pass it the
Message.text text.
// Send the message text by calling the server message function
function doSend() {
// If there’s message text, pass it to the server function msgFromClient

if (length(_root.Message.text) > 0) {
_root.client_nc.call("msgFromClient", null, _root.Message.text);
}
// Clear the message text

_root.Message.text = "";
44 Chapter 3
13 Create the setHistory function that the server calls to update the text in the History
dynamic text box.
// Update the History on the server with the message
client_nc.setHistory = function(msg) {
_root.History.text = msg;
}
To write the server-side ActionScript for this sample:
1 Create a new file using your server-side ActionScript editor, and write the event handler
onAppStart for initializing the application variables.
application.onAppStart = function()
{
trace("Begin sharing text");
// Get the server shared object users_so

application.users_so = SharedObject.get("users_so", false);
// Initialize the history of the text share

application.history = "";
// Initialize the unique user ID

application.nextId = 0;
}
2 Write the event handler onConnect for managing users and sending the history to all clients.
application.onConnect = function(newClient, name)
{
// Make this new client’s name the user’s name
newClient.name = name;
// Create a unique ID for this user while incrementing the

// application.nextID.
newClient.id = "u" + application.nextId++;
// Update the users_so shared object with the user’s name

application.users_so.setProperty(newClient.name, name);
// Accept the client’s connection

application.acceptConnection(newClient);
// Call the client function setHistory, and pass

// the initial history
newClient.call("setHistory", null, application.history);
// The client will call this function to get the server

// to accept the message, add the user’s name to it, and
// send it back out to all connected clients.
newClient.msgFromClient = function(msg) {
msg = this.name + ": " + msg + "\n";
application.history += msg;
application.users_so.send("msgFromSrvr", msg);
}
}
Exploring the Variety of Random
Documents with Different Content
The Project Gutenberg eBook of The Germ
Growers: An Australian story of adventure
and mystery
This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
Title: The Germ Growers: An Australian story of adventure and

mystery
Author: Robert Potter
Release date: September 17, 2019 [eBook #60312]
Language: English
Credits: Produced by MWS, David Wilson and the Online

Distributed
Proofreading Team at http://www.pgdp.net (This book
was
produced from images made available by the
HathiTrust
Digital Library.)
*** START OF THE PROJECT GUTENBERG EBOOK THE GERM

GROWERS: AN AUSTRALIAN STORY OF ADVENTURE AND MYSTERY
***
cover
i
THE GERM GROWERS.
THE GERM GROWERS.
iii
An Australian Story of Adventure and Mystery.
BY
ROBERT EASTERLEY and JOHN WILBRAHAM.
“His . . . . . . . .
Prosequitur dictis portaque emittit eburna.”
MELBOURNE:
MELVILLE, MULLEN, & SLADE.
LONDON: HUTCHINSON & CO.
1892.
[All rights reserved.]
v
TABLE OF CONTENTS.
———♦———
PAGE
Preliminary . . . . . . . . . . . . 1
CHAPTER I.
Disappearances . . . . . . . . . . . 6
CHAPTER II.
The Red Sickness . . . . . . . . . . 13
CHAPTER III.
At Sea . . . . . . . . . . . . . 26
CHAPTER IV.
Overland . . . . . . . . . . . . . 36
CHAPTER V.
Among the Blacks . . . . . . . . . . 58
CHAPTER VI.
vi Left Alone . . . . . . . . . . . . 86
CHAPTER VII.
The Cars . . . . . . . . . . . . . 97
CHAPTER VIII.
Signor Davelli . . . . . . . . . . . 131
CHAPTER IX.
The Seed Beds . . . . . . . . . . . 167
CHAPTER X.
Leäfar . . . . . . . . . . . . . . 202
CHAPTER XI.
Escape . . . . . . . . . . . . . 233
Conclusion . . . . . . . . . . . . 267
1
THE GERM GROWERS.

———♦———
PRELIMINARY.
When I first heard the name of Kimberley1 it did not remind me of

the strange things which I have here to record, and which I had
witnessed somewhere in its neighbourhood years before. But one
day, in the end of last summer, I overheard a conversation about its
geography which led me to recognise it as a place that I had
formerly visited under very extraordinary circumstances. The
recognition was in this wise. Jack Wilbraham and I were spending a
little while at a hotel in Gippsland, partly on a tour of pleasure and
partly, so at least we persuaded ourselves, on business. The fact
was, however, that for some days past, the business had quite
retreated into the background, or, to speak more correctly, we had
left
2
it behind at Bairnsdale, and had come in search of pleasure a
little farther south.
It was delicious weather, warm enough for light silk coats in the
daytime, and cold enough for two pairs of blankets at night. We had
riding and sea-bathing to our hearts’ content, and even a rough kind
of yachting and fishing. The ocean was before us—we heard its
thunder night and day; and the lakes were behind us, stretching
away to the promontory which the Mitchell cuts in two, and thence
to the mouth of the Latrobe, which is the highway to Sale. Three
times a week a coach passed our door, bound for the Snowy River
and the more savage regions beyond. Any day for a few shillings we
could be driven to Lake Tyers, to spend a day amidst scenery almost
comparable with the incomparable Hawkesbury. Last of all, if we
grew tired of the bell-birds and the gum-trees and the roar of the
ocean, we were within a day’s journey of Melbourne by lake and
river and rail.
It was our custom to be out all day, but home early and early to
bed. We used to take our meals in a low long room which was well
aired but poorly lighted, whether by day or night. And here, when
tea was over and the womenkind had retired, we smoked, whenever,
3
as often happened, the evening was cold enough to make a shelter
desirable; smoked and chatted. There was light enough to see the
smoke of your pipe and the faces of those near you; but if you were
listening to the chatter of a group in the other end of the room the
faces of the speakers were so indistinct as often to give a startling
challenge to your imagination if you had one, and if it was
accustomed to take the bit in its teeth. I sometimes caught myself
partly listening to a story-teller in the other end of the room and
partly fashioning a face out of his dimly seen features, which quite
belied the honest fellow’s real countenance when the flash of a
pipelight or a shifted lamp revealed it more fully.
Jack and I were more of listeners than talkers, and we were usually
amongst the earliest who retired. But one evening there was a good
deal of talk about the new gold-field in the north-west, and a keen-
looking bushman who seemed to have just returned from the place
began to describe its whereabouts. Then I listened attentively, and
at one point in his talk, I started and looked over at Jack, and I saw
that he was already looking at me. I got up and left the room
without a sign to him, but I knew that he would follow me, and he
did. It was bright moonlight, and when we met outside we strolled
4
down to the beach together. It was a wide, long, and lonely beach,
lonely to the very last degree, and it was divided from the house by
a belt of scrub near a mile wide. We said not a word to one another
till we got quite near the sea. Then I turned round and looked Jack
in the face and said, “Why, man, it must have been quite near the
place.”
“No,” said he, “it may have been fifty miles or more away, their
knowledge is loose, and their description looser, but it must be
somewhere in the neighbourhood, and I suppose they are sure to
find it.”
“I do not know,” said I; and after a pause I added, “Jack, it seems to

me they might pass all over the place and see nothing of what we
saw.”
“God knows,” he muttered, and then he sat down on a hummock of

sand and I beside him. Then he said, “Why have you never told the
story, Bob?”
“Don’t you know why, Jack?” I answered. “They would lock me up in

a madhouse; there would be no one to corroborate me but you, and
if you did so you would be locked up along with me.”
“That might be,” said he, “if they believed you; but they would not
believe you, they would think you were simply romancing.”
“What would be the good of speaking then?” said I.

5
“Don’t speak,” he repeated, “but write, litera scripta manet, you will
be believed sometime. But meanwhile you can take as your motto
that verse in Virgil about the gate of ivory, and that will save you
from being thought mad. You have a knack of the pen, Bob, you
ought to try it.”
“Well,” said I, “let it be a joint concern between you and me, and I’ll
do my best.”
Then we lit our pipes and walked home, and settled the matter in a
very few words on the way. I was to write, but all I should write was
to be read over to Jack, who should correct and supplement it from
his own memory. And no account of anything which was witnessed
by both of us was to stand finally unless it was fully vouched for by
the memory of both. Thus for any part of the narrative which would
concern one of us only that one should be alone responsible, but for
all of it in which we were both concerned there should be a joint
responsibility.
Out of this agreement comes the following history, and thus it

happens that it is told in the first person singular, although there are
two names on the title-page.
1 In North-west Australia. Return to text

6
CHAPTER I.
DISAPPEARANCES.
Before I begin my story I must give you some account of certain

passages in my early life, which seem to have some connection with
the extraordinary facts that I am about to put on record.
To speak more precisely, of the connection of one of them with

those facts there can be no doubt at all, and of the connection of the
other with them I at least have none.
When I was quite a boy, scarce yet fifteen years old, I happened to
be living in a parish on the Welsh coast, which I will here call
Penruddock. There were some bold hills inland and some very wild
and rugged cliffs along the coast. But there was also a well-sheltered
beach and a little pier where some small fishing vessels often lay.
Penruddock was not yet reached by rail, but forty miles of a splendid
7
road, through very fine scenery, took you to a railway station. And
this journey was made by a well-appointed coach on five days of
every week.
The people of Penruddock were very full of a queer kind of gossip,

and were very superstitious. And I took the greatest interest in their
stories. I cannot say that I really believed them, or that they
affected me with any real fear. But I was not without that mingled
thrill of doubt and wonder which helps one to enjoy such things. I
had a double advantage in this way, for I could understand the
Welsh language, although I spoke it but little and with difficulty, and
I often found a startling family likeness between the stories which I
heard in the cottages of the peasantry three or four miles out of
town and those which circulated among the English-speaking people
in whose village I lived.
There was one such story which was constantly reproduced under
various forms. Sometimes it was said to have happened in the last
generation; sometimes as far back as the civil wars, of which,
strange to say, a lively traditional recollection still remained in the
neighbourhood; and sometimes it seemed to have been handed
down from prehistoric times, and was associated with tales of
enchantment
8
and fairyland. In such stories the central event was
always the unaccountable disappearance of some person, and the
character of the person disappearing always presented certain
unvarying features. He was always bold and fascinating, and yet in
some way or other very repulsive. And when you tried to find out
why, some sort of inhumanity was always indicated, some
unconscious lack of sympathy which was revolting in a high degree
or even monstrous. The stories had one other feature in common, of
which I will tell you presently.
I seldom had any companions of my own age, and I was in

consequence more given to dreaming than was good for me. And I
used to marshal the heroes of these queer stories in my day-dreams
and trace their likeness one to another. They were often so very
unlike in other points, and yet so strangely like in that one point. I
remember very well the first day that I thought I detected in a living
man a resemblance to those dreadful heroes of my Welsh friend’s
folk-lore. There was a young fellow whom I knew, about five or six
years my senior, and so just growing into manhood. His name, let us
say, was James Redpath. He was well built, of middle height, and, as
I thought, at first at least, quite beautiful to look upon. And, indeed,
why
9
I did not continue to think so is more than I can exactly say. For
he possessed very fine and striking features, and although not very
tall his presence was imposing. But nobody liked him. The girls
especially, although he was so good-looking, almost uniformly
shrank from him. But I must confess that he did not seem to care
much for their society.
I went about with him a good deal at one time on fishing and
shooting excursions and made myself useful to him, and except that
he was rather cruel to dogs and cats, and had a nasty habit of
frightening children, I do not know that I noticed anything particular
about him. Not, at least, until one day of which I am going to tell
you. James Redpath and I were coming back together to
Penruddock, and we called at a cottage about two miles from the
village. Here we found a little boy of about four years old, who had
been visiting at the cottage and whom they wanted to send home.
They asked us to take charge of him and we did so. On the way
home the little boy’s shoe was found to have a nail or a peg in it that
hurt his foot, and we were quite unable to get it out. It was nothing,
however, to James Redpath to carry him, and so he took him in his
arms. The little boy shrank and whimpered as he did so. James had
under
10
his arm some parts of a fishing-rod and one of these came in
contact with the little boy’s leg and scratched it rather severely so as
to make him cry. I took it away and we went on. I was walking a
little behind Redpath, and as I walked I saw him deliberately take
another joint of the rod, put it in the same place and then watch the
little boy’s face as it came in contact with the wire, and as the child
cried out I saw quite a malignant expression of pleasure pass over
James’s face. The thing was done in a moment and it was over in a
moment; but I felt as if I should like to have killed him if I dared. I
always dreaded and shunned him, more or less, afterwards, and I
began from that date to associate him with the inhuman heroes of
my Welsh stories.
I don’t think that I should ever have got over the dislike of him
which I then conceived, but I saw the last of him, at least
Penruddock saw the last of him, about three months later. I had
been sitting looking over the sea between the pier and the cliffs and
trying to catch a glimpse of the Wicklow Mountains which were
sometimes to be seen from that point. Just then James Redpath
came up from the beach beyond the pier, and passing me with a
brief “good morning,” went away inland, leaving the cliffs behind
11
him. I don’t know how long I lay there, it might be two hours or
more, and I think I slept a little. But I suddenly started up to find it
high day and past noon, and I began to think of looking for some
shelter. There was not a cloud visible, but nevertheless two shadows
like, or something like, the shadows of clouds lay near me on the
ground. What they were the shadows of I could not tell, and I was
about to get up to see, for there was nothing to cast such a shadow
within the range of my sight as I lay. Just then one of the shadows
came down over me and seemed to stand for a moment between
me and the sun. It had a well-defined shape, much too well defined
for a cloud. I thought as I looked that it was just such a shadow as
might be cast by a yawl-built boat lying on the body of a large
wheelbarrow. Then the two shadows seemed to move together and
to move very quickly. I had just noticed that they were exactly like
one another when the next moment they passed out of my sight.
I started to my feet with a bound, my heart beating furiously. But

there was nothing more to alarm the weakest. It was broad day.
Houses and gardens were to be seen close at hand and in every
direction but one, and in that direction there were three or four
fishermen
12
drawing their nets. But as I looked away to the part of the
sky where the strange cloudlike shadows had just vanished, I
remembered with a shudder that other feature in common of the
strange stories of which I told you just now. It was a feature that
forcibly reminded me of what I had just witnessed. Sometimes in the
later stories you would be told of a cloud coming and going in an
otherwise cloudless sky. And sometimes in the elder stories you
would be told of an invisible car, invisible but not shadowless. I used
always to identify the shadow of the invisible car in the elder stories
with the cloud in the later stories, the cloud that unaccountably
came and went.
As I thought it all over and tried to persuade myself that I had been
dreaming I suddenly remembered that James Redpath had passed
by a few hours before, and as suddenly I came to the conclusion
that I should never see him again. And certainly he never was again
seen, dead or alive, anywhere in Wales or England. His father, and
his uncle, and their families, continued to live about Penruddock, but
Penruddock never knew James Redpath any more. Whether I myself
saw him again or not is more than I can say with absolute certainty.
You shall know as much as I know about it if you hear my story to
the end.
13
CHAPTER II.
THE RED SICKNESS.
Of course James Redpath’s disappearance attracted much attention,

and was the talk not only of the village, but of the whole country-
side. It was the general opinion that he must have been drowned by
falling over the cliffs, and that his body had been washed out to sea.
I proved, however, to have been the very last person to see him,
and my testimony, as far as it went, was against that opinion. For I
certainly had seen him walking straight inland. Of course he might
have returned to the coast afterwards, but at least nobody had seen
him return. I gave a full account of place and time as far as I could
fix them, and I mentioned the queer-looking clouds and even
described their shape. This, I remember, was considered to have
some value as fixing my memory of the matter, but no further notice
14
was taken of it. And I myself did not venture to suggest any
connection between it and Redpath’s disappearance, because I did
not see how I could reasonably do so. I had, nevertheless, a firm
conviction that there was such a connection, but I knew very well
that to declare it would only bring a storm of ridicule upon me.
But a public calamity just then befell Penruddock which made men
forget James Redpath’s disappearance. A pestilence broke out in the
place of which nobody knew either the nature or the source. It
seemed to spring up in the place. At least, all efforts to trace it were
unsuccessful. The first two or three cases were attributed to some
inflammatory cold, but it soon became clear that there were specific
features about it, that they were quite unfamiliar, that the disease
was extremely dangerous to life and highly infectious.
Then a panic set in, and I believe that the disease would soon have
been propagated all over England and farther, if it had not been for
the zeal and ability of two young physicians who happened very
fortunately to be living in the village just then. Their names were
Leopold and Furniss. I forget if I ever knew their Christian names.
We used to call them Doctor Leopold and Doctor Furniss. They had
finished their studies for some little time, but they found it advisable
15
on the score of health to take a longish holiday before commencing
practice, and they were spending part of their holiday at
Penruddock. They were just about to leave us when the disease I
am telling you of broke out.
The first case occurred in a valley about two miles from the village.
In this valley there were several cottages inhabited mostly by farm
labourers and artisans. These cottages lay one after another in the
direction of the rising ground which separated the valley from
Penruddock. Then there were no houses for a considerable space.
Then, just over the hill, there was another and yet another. The
disease had made its way gradually up the hill from one cottage to
another, day after day a fresh case appearing. Then there had been
no new cases for four days, but on the fifth day a new case
appeared in the cottage just over the brow of the hill. And when this
became known, also that every case (there had now been eleven)
had hitherto been fatal, serious alarm arose. Then, too, the disease
became known as the “red sickness.” This name was due to a
discoloration which set in on the shoulders, neck, and forehead very
shortly after seizure.
How the two doctors, as we called them, became armed with the
needful powers I do not know. They certainly contrived to obtain
some
16
sort of legal authority, but I think that they acted in great
measure on their own responsibility.
By the time they commenced operations there were three or four

more cases in the valley, and one more in the second cottage on the
Penruddock side. There was a large stone house, partly ruinous, in
the valley, near the sea, and hither they brought every one of the
sick. Plenty of help was given them in the way of beds, bedding, and
all sorts of material, but such was the height which the panic had
now attained that no one from the village would go near any of the
sick folk, nor even enter the valley. The physicians themselves and
their two men servants, who seemed to be as fearless and brave as
they, did all the work. Fortunately, the two infected cottages on the
Penruddock side were each tenanted only by the person who had
fallen ill, and the tenant in each case was a labourer whose work lay
in the valley. The physicians burnt down these cottages and
everything that was in them. Then they established a strict
quarantine between the village and the valley. There was a light
fence running from the sea for about a mile inland, along the brow
of the rising ground on the Penruddock side. This they never passed
nor suffered any one to pass, during the prevalence of the sickness.
Butchers
17
and bakers and other tradesmen left their wares at a given
point at a given time, and the people from the valley came and
fetched them.
The excitement and terror in Penruddock were very great. All but the
most necessary business was suspended, and of social intercourse
during the panic there was next to none. Ten cases in all were
treated by the physicians, and four of these recovered. The last two
cases were three or four days apart, but they were no less malignant
in character: the very last case was one of the fatal ones. I learned
nothing of the treatment; but the means used to prevent the disease
spreading, besides the strict quarantine, were chiefly fire and lime.
Everything about the sick was passed through the fire, and of these
everything that the fire would destroy was destroyed. Lime, which
abounded in the valley, was largely used.
A month after the last case the two physicians declared the
quarantine at an end, and a month later all fear of the disease had
ceased. And then the people of the village began to think of
consoling themselves for the dull and uncomfortable time they had
had, and of doing some honour to the two visitors who had served
the village so well. With this double purpose in view a picnic on a
large
18
scale was organized, and there was plenty of eating and
drinking and speech-making and dancing, all of which I pass over.
But at that picnic I heard a conversation which made a very powerful
impression on me then, and which often has seemed to provide a
bond which binds together all the strange things of which I had
experience at the time and afterwards.
In the heat of the afternoon I had happened to be with Mr. Leopold

and Mr. Furniss helping them in some arrangements which they were
making for the amusement of the children who took part in the
picnic. After these were finished they two strolled away together to
the side of a brook which ran through the park where we were
gathered. I followed them, attracted mainly by Mr. Furniss’s dog, but
encouraged also by an occasional word from the young men. At the
brook Mr. Furniss sat upon a log, and leaned his back against a
rustic fence. The dog sat by him; a very beautiful dog he was, black
and white, with great intelligent eyes, and an uncommonly large and
well-shaped head. He would sometimes stretch himself at length,
and then again he would put his paw upon his master’s shoulder and
watch Mr. Leopold and me.
Mr.
19
Leopold stood with his back to an oak-tree, and I leant against
the fence beside him listening to him. He was a tall, dark man, with
a keen, thoughtful, and benevolent expression. He was quite strong
and healthy-looking, and there was a squareness about his features
that I think one does not often see in dark people. Mr. Furniss was of
lighter complexion and hardly as tall; there was quite as much
intelligence and benevolence in his face, but not so much of what I
have called thoughtfulness as distinguished from intelligence, and
there was a humorous glint in his eye which the other lacked. They
began to talk about the disease which had been so successfully dealt
with, and this was what they said:—
Leopold. Well, Furniss, an enemy hath done this.
Furniss. Done what? The picnic or the red sickness?
Leopold. The red sickness, of course. Can’t you see what I mean?
Furniss. No, I can’t. You’re too much of a mystic for me, Leopold;
but I’ll tell you what, England owes a debt to you and me, my boy,
for it was near enough to being a new edition of the black death or
the plague.
Leopold. Only the black death and the plague were imported, and
this
20
was indigenous. It sprung up under our noses in a healthy
place. It came from nowhere, and, thank God, it is gone nowhither.
Furniss. But surely the black death and the plague must have begun
somewhere, and they too seem to have gone nowhither.
Leopold. You’re right this far that they all must have had the same
sort of beginning. Only it is given to very few to see the beginning,
as you and I have seen it, or so near the beginning.
Furniss. Now, Leopold, I hardly see what you are driving at. I am not
much on religion, as they say in America, but I believe there is a
Power above all. Call that Power God, and let us say that God does
as He pleases, and on the whole that it is best that He should. I
don’t see that you can get much further than that.
Leopold. I don’t believe that God ever made the plague, or the black
death, or the red sickness.
Furniss. Oh, don’t you? Then you are, I suppose, what the
churchmen call a Manichee—you believe in the two powers of light
and darkness, good and evil. Well, it is not a bad solution of the
question as far as it goes, but I can hardly accept it.
Leopold. No, I don’t believe in any gods but the One. But let me
explain.
21
That is a nice dog of yours, Furniss. You told me one day
something about his breeding, and you promised to tell me more.
Furniss. Yes, it is quite a problem in natural history. Do you know,

Tommy’s ancestors have been in our family for four or five
generations of men, and, I suppose, that is twenty generations of
dogs.
Leopold. You told me something of it. You improved the breed

greatly, I believe?
Furniss. Yes; but I have some distant cousins, and they have the
same breed and yet not the same, for they have cultivated it in quite
another direction.
Leopold. What are the differences?
Furniss. Our dogs are all more or less like Tommy here, gentle and
faithful, very intelligent, and by no means deficient in pluck. My
cousin’s dogs are fierce and quarrelsome, so much so that they have
not been suffered for generations to associate with children. And so
they have lost intelligence and are become ill-conditioned and low-
lived brutes.
Leopold. But I think I understood you to say that the change in the
breed did not come about in the ordinary course of nature.
Furniss. I believe not. I heard my grandfather say that his father had
told him that when he was a young man he had set about improving
22
the breed. He had marked out the most intelligent and best
tempered pups, and he had bred from them only and had given
away or destroyed the others.
Leopold. And about your cousin’s dogs?
Furniss. Just let me finish. It seems that while one brother began to
cultivate the breed upward, so to speak, another brother was living
in a part of the country where thieves were numerous and daring,
and there were smugglers and gipsies, and what not, about. And so
he began to improve the breed in quite another direction. He
selected the fierce and snappish pups and bred exclusively from
them.
Leopold. And so from one ancestral pair of, say, a hundred or a

hundred and fifty years ago, you have Tommy there, with his
wonderful mixture of gentleness and pluck, and his intelligence all
but human, and your cousin has a kennel of unintelligent and
bloodthirsty brutes, that have to be caged and chained as if they
were wild beasts.
Furniss. Just so, but I don’t quite see what you are driving at.
Leopold. Wait a minute. Do you suppose the germs of cow-pox and

small-pox to be of the same breed?
Furniss. Well, yes; you know that I hold them to be specifically

identical. I see what you are at now.
Leopold.
23
But one of them fulfils some obscure function in the
physique of the cow, some function certainly harmless and probably
beneficent, and the other is the malignant small-pox of the London
hospitals.
Furniss. So you mean to infer that in the latter case the germ has
been cultivated downwards by intelligent purpose.
Leopold. What if I do?
Furniss. You think, then, that there is a secret guild of malignant

men of medicine sworn to wage war against their fellow-men, that
they are spread over all the world and have existed since before the
dawn of history. I don’t believe that there are any men as bad as
that, and if there were, I should call them devils and hunt them
down like mad dogs.
Leopold. I don’t wish to use misleading words, but I will say that I
believe there are intelligences, not human, who have access to
realms of nature that we are but just beginning to explore; and I
believe that some of them are enemies to humanity, and that they
use their knowledge to breed such things as malignant small-pox or
the red sickness out of germs which were originally of a harmless or
even of a beneficent nature.
Furniss.
24
Just as my cousins have bred those wild beasts of theirs out
of such harmless creatures as poor Tommy’s ancestors.
Leopold. Just so.
Furniss. And you think that we can contend successfully against such
enemies.
Leopold. Why not? They can only have nature to work upon. And
very likely their only advantage over us is that they know more of
nature than we do. They cannot go beyond the limits of nature to do
less or more. As long as we sought after spells and enchantments
and that sort of nonsense we were very much at their mercy. But we
are now learning to fight them with their own weapons, which
consist of the knowledge of nature. Witness vaccination, and witness
also our little victory over the red sickness.
Furniss. You’re a queer mixture, Leopold, but we must get back to

the picnic people.
And so they got up and went back together to the dancers, nodding
to me as they went. I sat there for awhile, going over and over the
conversation in my mind and putting together my own thoughts and
Mr. Leopold’s.
Then I joined the company and was merry as the merriest for the
remainder
25
of the day. But that night I dreamt of strange-looking
clouds and of the shadows of invisible cars, and of demons riding in
the cars and sowing the seeds of pestilence on the earth and
catching away such evil specimens of humanity as James Redpath to
reinforce the ranks of their own malignant order.
26
CHAPTER III.
AT SEA.
It is my purpose to pass briefly over everything in my own history

which does not concern the tale that I have to tell, and there is very
little therefore for me to say about the seven or eight years which
followed upon the events at Penruddock which I have just recorded.
I went in due course to Oxford, where I stayed the usual time. I did
not make any great failures there, nor did I gain much distinction. I
was a diligent reader, but much of my reading was outside the
regulation lines. The literature of my own country, the poetry of
mediæval Italy, and the philosophy of modern Germany, more than
divided my attention with classics and mathematics. Novels, mostly
of the sensational type, amused me in vacations and on holidays,
but very seldom found their way into my working days.
I27travelled over most of England, Scotland, and Ireland, and spent

some time in some of the principal cities of the Continent. I became
a fair linguist, speaking German, French, and Italian, with some
fluency, although my accent always bewrayed me. I took a second
class in classics, bade adieu to Oxford, and began to make up my
mind as to what I should do with my life. I had thought of the
various professions in turn, and had decided against them all; and,
finally, as I had no taste for idleness, and as I had some money, I

Macromedia Flash Communication Server MX 1st ed Edition Kevin Towes 2024 scribd download

Uploaded by

Copyright:

Available Formats

Macromedia Flash Communication Server MX 1st ed Edition Kevin Towes 2024 scribd download

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Macromedia Flash Communication Server MX 1st ed Edition Kevin Towes 2024 scribd download

Uploaded by

Copyright:

Available Formats

Download the full version of the ebook at

Macromedia Flash Communication Server MX 1st

Explore and download more ebook at https://ebookultra.com

Sams Teach Yourself Macromedia Flash MX 2004 in 24 Hours

Macromedia ColdFusion MX Development 1st Edition Eric Ladd

How To Use Macromedia Dreamweaver MX and Fireworks MX 1st

Flash MX Games ActionScript for Artists Nik Lever

How to do everything with Macromedia Flash 1st Edition

Flash MX 2004 at Your Fingertips Get In Get Out Get

Managerial communication 1st ed Edition Bell

Server study guide 2nd ed Edition Brad Hryhoruk

Sorenson™ Spark™ video compression and decompression technology licensed from

First Edition: May 2002

Welcome to Macromedia Flash Communication Server MX!

About the Flash Communication Server documentation

About This Manual 5

Overview of Flash Communication Server architecture

Flash Player Flash Player

Flash authoring provides an easy way to create audio/visual applications in ActionScript.

FLV NetStream object

About Flash Communication Server 9

About Flash Communication Server 11

To place a Video object on the Stage:

Client-server object communications

Client-side object Corresponding server-side object

my_nc (NetConnection object) my_client (Client object or application.clients

my_ns (NetStream object) my_server_stream (Stream object)

my_so (remote shared object) my_server_so (server-side shared object)

Client-side call Server-side call

my_nc.call("doThing", myCallbackFcn, 1, "foo") my_client.doThing(1, "foo")

my_so.send("doThing", 1, "foo") my_server_so.doThing(1, "foo")

Server-side call Client-side call

my_client.call ("doThing", myCallbackFcn, my_nc.doThing (1, "foo")

my_server_stream.send ("doThing", 1, my_ns.doThing (1, "foo")

my_server_so.send("doThing", 1, "foo") my_so.doThing(1, "foo")

About Flash Communication Server 13

Local shared objects

Remote shared objects

Server-side shared objects

Applications and application instances

About Flash Communication Server 15

// Another instance of application "support"

File types used by Flash Communication Server

Connecting to the server

About Flash Communication Server 17

Opening a connection to the server

To use ActionScript to connect to the server:

2 Follow this command with a connect command:

In this basic syntax for NetConnection.connect (omitting optional parameters), targetURI

// Connects to the instance named appInstance

Examining the sample connection application

To view the source file:

Open the doc_connect.fla file located in the \Macromedia\Flash

To see the sample in action:

About Flash Communication Server 19

To create the user interface for this sample:

5 Resize the Published_video video object to 200 x 150.

To write the ActionScript for this sample:

client_nc = new netConnection();

out_ns = new netStream(_root.client_nc);