MACROMEDIA FIREWORKS 2-USING FIREWORKS Mounting instructions

Using Flash Media Server
Edge Servers

Trademarks
1 Step RoboPDF, ActiveEdit, ActiveTest, Authorware, Blue Sky Software, Blue Sky, Breeze, Breezo, Captivate, Central,
ColdFusion, Contribute, Database Explorer, Director, Dreamweaver, Fireworks, Flash, FlashCast, FlashHelp, Flash Lite,
FlashPaper, Flash Video Encoder, Flex, Flex Builder, Fontographer, FreeHand, Generator, HomeSite, JRun, MacRecorder,
Macromedia, MXML, RoboEngine, RoboHelp, RoboInfo, RoboPDF, Roundtrip, Roundtrip HTML, Shockwave, SoundEdit,
Studio MX, UltraDev, and WebHelp are either registered trademarks or 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, service marks, or trade names of Macromedia, Inc. or other entities and
may be registered in certain jurisdictions including internationally.
Third-Party Information
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.
Jabber is a registered trademark of the Jabber Software Foundation.
Sorenson™ Spark™ video compression and decompression technology licensed from
Sorenson Media, Inc.
Copyright © 2002-2005 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 written approval from
Macromedia, Inc. Notwithstanding the foregoing, the owner or authorized user of a valid copy of the software with which
this manual was provided may print out one copy of this manual from an electronic version of this manual for the sole
purpose of such owner or authorized user learning to use such software, provided that no part of this manual may be
printed out, reproduced, distributed, resold, or transmitted for any other purposes, including, without limitation,
commercial purposes, such as selling copies of this documentation or providing paid-for support services.
Acknowledgments
Project Management: Suzanne Smith
Writing: John Norton, Suzanne Smith
Editing: Evelyn Eldridge, Mary Ferguson, Lisa Stanziano, Anne Szabla
Production Management: Adam Barnett
Media Design and Production: Aaron Begley, Paul Benkman, John Francis, Mario Reynoso
First Edition: October 2005
Macromedia, Inc.
601 Townsend St.
San Francisco, CA 94103

3
Contents
Using Edge and Origin Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Introducing edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
How edge servers work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Caching data in edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Deploying edge servers in the DMZ . . . . . . . . . . . . . . . . . . . . . . . . . .9
Explicit and implicit proxies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Routing information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Connecting to an edge server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Detecting the presence of proxy servers . . . . . . . . . . . . . . . . . . . . . 13
Chaining edge servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Configuring edge servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Deploying a cluster of edge servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Connecting to a cluster of edge servers. . . . . . . . . . . . . . . . . . . . . . 16
Enrolling proxy servers in the cluster . . . . . . . . . . . . . . . . . . . . . . . . 16
Accessing applications through an edge cluster . . . . . . . . . . . . . . 16
Clustering reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Setting up origin and proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . 18
Maintaining edge server clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Clearing the edge server cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4Contents

5
Using Edge and Origin
Servers
This chapter describes the various strategies for deploying Flash Media Server with edge and
origin servers.
Introducing edge servers
Until this release of Flash Media Server, clients always connected directly to the computer
where the application was running. These applications were running locally, since their
execution occurred on the same computer that the clients were connected to. This release of
Flash Media Server introduces the concept of remote execution of applications. Flash Media
Server can now run applications locally as an origin server or remotely as edge servers. Edge
servers are not a different kind of Flash Media Server, rather, they are configured to run
applications remotely.
Deploying edge servers in your organization offers significant benefits. Enhanced security is
one benefit. Applications running on the origin server are no longer directly exposed to the
Internet. All requests for Flash Media Server services are routed through known and secure
connection points. These connectors are called edge, or proxy, servers; the terms are
interchangeable. Administrators can monitor the traffic on edge servers. The access log files
for each edge server lets administrators verify that the connections are authorized. The log files
also identify unauthorized requests for connections.
The edge server-origin server deployment is flexible. Edge servers let administrators scale up
or redistribute access to Flash Media Server without dismantling their current deployment.
Administrators can add edge servers. Administrators can reallocate edge servers to match
realignments of users and sites within an organization, or changes in the flow of traffic among
the sites.

6 Using Edge and Origin Servers
Deploying edge servers lets administrators distribute the incoming connection requests for
Flash Media Server services. Traffic between clients and the origin server uses the existing
bandwidth and system resources more efficiently. More traffic occurs locally between the
clients’ computers and the edge server. Without edge servers, all clients have to connect to a
Flash Media Server origin server, no matter where that server is located.
Edge servers mediate communications traffic between the organization’s trusted network and
an untrusted network such as the Internet. Using edge servers does not remove the need for a
firewall to manage the traffic at an IP level, but does provide an additional layer of security at
the application level.
How edge servers work
With an edge-origin deployment strategy, all connection requests from users’ computers for
Flash Media Server services are redirected to an edge server. The edge server receives the
request from the user’s computer, but the edge server is not running the application. The edge
server makes the connection to another computer, called the origin server, where the
application is running. When the origin server fulfills the request for Flash Media Server
services, it sends the application’s data back to the edge server, which in turn forwards the data
to the client (the user’s computer).
It may seem to the users that they are directly connected to the origin server where the
application is located. The edge server does make it appear as if it is running the application.
The edge server’s role, however, is to mediate the communications between clients and the
origin server. Edge servers authenticate the users and authorize their requests for web services.
For example, when Flash Media Server is deployed solely on one computer and is running just
one application instance, system and network resources may not always be sufficient when a
large number of users in an organization want to connect almost simultaneously to Flash
Media Server from multiple locations. Such might be the case in an enterprise-wide meeting
or conference. When too many users want to access the same application at the same time, the
existing bandwidth and system resources can be overwhelmed. Increased latency is another
indication that resources need to be reconfigured or reallocated.
Every connection into the origin server consumes resources independent of the actual data
flowing through the connection. As the number of connections increase, this load can become
inordinately large and adversely affect the server performance. The edge server greatly
mitigates this problem by aggregating connections. The edge multiplexes the connections
from a large number of clients on to one connection to the origin server.

Introducing edge servers 7
Such constraints may prompt the Flash Media Server and network administrators to consider
a different deployment strategy. The strategy involves configuring Flash Media Server to
redistribute the load on system and bandwidth resources by running some virtual hosts as
edge servers and other virtual hosts as origin servers.
Rather than forwarding every request to the origin server and consuming resources for such
repetitive tasks, the edge server collects the requests from a large number of clients and
aggregates them into one connection to the origin server. All communications between edge
and origin servers happen transparently to the users.
To distribute the demands on network and system resources, administrators can assign the
users in a geographical region or functional area of the organization to a specific edge server.
For example, one edge server might aggregate and forward requests from users in Tokyo and
another might aggregate and forward requests from Paris. The edge servers in Paris and Tokyo
gather the requests from their clients and forward them to the origin server located in another
secured location, such as Chicago.
Edge Server
Tokyo
Edge Server
Paris
Origin Server
Chicago
End User
End User
End User
End User
End User
End User
End User
End User
End User
End User

8 Using Edge and Origin Servers
Users in these zones always access the origin server through their assigned edge servers. These
edge servers receive the responses from the origin server, then distribute them back to the
clients (the users’ computers) in their respective zones: Paris or Tokyo. The edge also stores the
data received from the origin server in a cache, and makes it available to other clients that
connect to this edge server. Recycling the data is one more way that edge servers use resources
efficiently. Caching static content reduces the overall load placed on the origin server.
A networked Flash Media Server deployment involves multiple edge servers; these can be
deployed individually or in clusters. Edge servers can also be chained, where one edge server
collects and aggregates the connection requests from other edge servers and their clients, then
transmits the requests to an origin server.
Origen
Server
Client (Users)
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Edge
Server
Client (Users)
Client (Users)
Client (Users)
Client (Users)
Client (Users)
Client (Users)
Client (Users
)
Client (Users) Client (Users)

Introducing edge servers 9
Caching data in edge servers
An edge server is designed to intercept the requests for Flash Media Server services from users
in a particular zone, collect or aggregate these requests, and transmit them to the origin server.
The origin server returns the results to the edge server, which in turn sends the data back to
the user’s client computer. The edge server also stores this information in its cache, where
other users or clients assigned to the same edge server can access it. In this scenario, fewer
requests for services are forwarded to the origin server.
The edge server caches data such as video streams and shared objects. When a user requests
data that is found in the edge server’s cache, it returns the data to the requesting client (the
user’s computer) without ever calling upon the origin server. This detour is transparent to the
user. The edge server is conserving bandwidth by not connecting to the origin server. In this
scenario, no demands are placed on the origin server.
Deploying edge servers in the DMZ
Edge servers may be deployed in the demilitarized zone (DMZ) of a corporate network. A
DMZ is an isolated network placed between an organization’s trusted network and the
Internet’s untrusted network. In this deployment, the edges function as proxy servers for all
Real Time Messaging Protocol (RTMP) traffic that flows through the organization’s network.
Deploying edge servers in the DMZ provides one more layer of defense between the user’s
Internet connection and the origin server. All traffic that comes from the Internet with Flash
Media Server as its destination must pass through an edge server.

10 Using Edge and Origin Servers
With the edge servers sitting in the DMZ, the network operators can open access to port
1936, avoiding the system overhead and risk of HTTP tunneling. Because the edge server
performs stream splitting and stream caching, it uses the connection to the origin server
efficiently, reducing the Internet bandwidth cost. The user also benefits from the more reliable
connectivity.
Explicit and implicit proxies
Edge servers are defined by the values in the configuration files. Both explicit and implicit
(also called anonymous) proxies intercept and aggregate the clients’ requests to connect to the
applications running on an origin server. The explicit edge server prefixes its address to the
origin server’s Uniform Resource Identifier (URI). This configuration makes the client (the
user’s computer) aware of the proxy. The URI in the explicit proxy specifies the edge servers
that will intercept the clients’ connection requests to the origin server.
The identity (the IP address and port number) of the implicit proxy is hidden from the client.
The implicit proxy does not change or modify the routing information in the incoming URI
before it connects the clients to the origin server. Edge servers are also defined as implicit
proxies through the Flash proxy auto-detection process (FPAD).
Flash Media Server and network administrators can deploy Flash Media Server and route the
incoming connection requests to the origin server through one or more edge servers. These
implicit edges are transparent because the client is unaware of the proxy. They are also
sometimes referred to as interception proxies. This deployment strategy is useful to ISP and
telco providers for optimizing the flow of RTMP traffic through their networks.
Firewall,
Router,
Load Balancer Edge Server Cluster
80,
443,
1935
Origin
Server
DMZ
80
443
1935
1936
End User
End User
End User
End User
End User
End User
End User

Introducing edge servers 11
Administrators can explicitly specify that any connection request to an origin server be
automatically routed through an edge or proxy server. For example, if your applications are
running on fms.foo.com, you can redirect the connection request from the users’ computers
to another server (or virtual host) called fmsproxy.foo.com, which is configured to run in
remote mode.
Instead of making the usual connection to the applications with the following connection
string:
rtmp://fms.foo.com/app/inst
the clients are redirected through the edge, which prefixes its protocol and hostname to an
existing URI:
rtmp://fmsproxy.foo.com/?rtmp://fms.foo.com/app/inst
The prefix contains only the protocol, hostname, and optionally the port number. The URI
must always end with a trailing slash. A question mark (?) separates the proxy’s prefix from the
main URI.
Reverse proxies
Sometimes you cannot configure the client (as is the case with mobile phones and devices) to
send their connection requests for Flash Media Server services through an edge or proxy
server. In these cases you might set up one or more reverse proxy servers and position them
closer to the origin server. Reverse proxies are usually located within an organization’s DMZ
and control access to Flash Media Server resources from clients connecting through the
Internet to an origin server located behind the firewall. Reverse proxies redirect incoming
connection requests instead of outgoing connection requests as in the case of explicit and
anonymous proxies.
The reverse proxy intercepts all connection requests that arrive from clients, as well as any
edge servers positioned on the outer side of a firewall, authenticates these requests, and then
forwards them to the origin server. The origin server is always located on the inner side of the
firewall. With a reverse proxy, you limit the access to an origin server on the trusted network.
The reverse proxy blocks all traffic except what its configuration allows for. A reverse proxy
also blocks any attempt to access other servers and their resources on the trusted network.
A reverse edge server hides the presence and location of the origin server. Administrators can
explicitly determine that connection requests to Flash Media Server be automatically routed
through a reverse edge or proxy server. You can use RTMPS to configure a reverse proxy to
listen on port 80 for non-secure connection requests and port 443 for secure requests.

12 Using Edge and Origin Servers
For example, if your applications are running on fms-secure.foo.com, you can direct the
connection requests from clients’ devices or computers to the proxy server (or virtual host)
called fms.foo.com, which makes the connection to fms-secure.foo.com, where your
applications are running. The client is not aware that its request is being sent to another
server.
Routing information
The Flash Media Server or network administrator specifies the routing information for a
proxy or edge server in the RouteEntry tags of the Vhost.xml configuration file.
Administrators use the Vhost.xml file to configure how and where to route connections to the
desired destination.
The protocol attribute in the RouteEntry tag specifies the protocol of the outgoing
connection. This attribute must be set to either "rtmp" or "rtmps" to indicate a nonsecure or
secure connection.
The RouteTable container tag holds all the RouteEntry tags. For example, the RouteTable
container may hold one RouteEntry tag to specify a secure outgoing connection by using
RTMP, and another RouteEntry tag that specifies the nonsecure RTMP connection. If a
protocol is not specified, the outgoing connection uses the same protocol as the incoming
connection.
For detailed information on these routing tags, see “Vhost.xml file” in Managing Flash Media
Server.
Connecting to an edge server
Clients can explicitly connect to a specific edge server when they know it is available. You use
a URI in a wrapped format to make the connection to an explicit proxy:
rtmp://edge/?rtmp://origin/app
You can also connect to a chain of proxies by forming a string that routes the outgoing
connection requests through a sequence of explicitly identified proxies:
rtmp://edge1/?rtmp://edge2/?rtmp?://edge3/?rtmp://edge4/?rtmp://origin/app
As the connection moves through each edge in the chain, Flash Media Server drops the first
token in the string. After making the connection to edge1, the connection string changes to:
rtmp://edge2/?rtmp?://edge3/?rtmp://edge4/?rtmp://origin/app

Introducing edge servers 13
Detecting the presence of proxy servers
Flash Player 8 automatically detects any edge servers in its proximity. When an edge server is
available, Flash Player automatically routes the connection from the client to the origin server
through the proxy server. These edge servers are defined as implicit proxies since the client is
generally unaware that its communication with Flash Media Server is being routed through a
proxy. This use of an implicit proxy allows your current applications to continue working
without any changes. Flash Player exposes the proxy information to the client only through
the read-only properties on the NetConnection object.
For more information on the NetConnection class, see the Client-Side Media ActionScript
Language Reference.
Chaining edge servers
You can chain together any number of edges when you make connections to the origin server.
The following URI shows how two explicit proxies are chained together to direct connection
requests to the origin server:
rtmp://proxy1/?rtmp://proxy2/?rtmp://origin/app/inst
When you use URL decoration to chain proxies, Flash Player 7 and earlier versions may have
problems with shared objects because of the embedded question mark (?) character in the
URL.
A workaround is available for clients who use earlier versions of Flash Player. You can resolve
the problem by using the following function to escape the question marks from the URI
before passing the URI to the shared object.
function escapeURI(uri) {
index = uri.indexOf(‘?’);
if (index == -1) return uri;
prefix = uri.substring(0, index);
uri = uri.substring(index);
return prefix += escape(uri);
}
You call this function on the URI you are about to pass into the shared object, then use the
result of the function instead of the original URI. Flash Player 8 resolves this problem for
Flash Media Server.
NOTE
Earlier versions of Flash Player cannot automatically detect edge servers in their
proximity.

14 Using Edge and Origin Servers
A second problem surfaces when RTMPT is specified in the URI. You may specify this
protocol only for the first prefix. The following are valid URIs:
rtmpt://foo/?rtmp://bar/app/inst
rtmpt://foo:443/?rtmp://bar/app/inst
The following are invalid URIs:
rtmpt://foo/?rtmpt://bar/app/inst
rtmp://foo/?rtmpt://bar/app/inst
Configuring edge servers
All Flash Media Server functionalities—live streaming, on-demand streaming, messaging,
shared object handling, scripting—take place as application instances. Application developers
write scripts to create Flash Media Server applications, instances of which are then distributed
by the Flash Media Server. A minimal application runs on the edge to perform connection
aggregation, stream splitting, stream caching, and smart state management. This separation of
tasks off loads to the edge server a large portion of the processing from the main application
that runs on the origin server.
Flash Media Server and network administrators can configure edge servers to function in
different ways. The XML configuration files define how the edge servers connect clients to the
origin server. These settings determine how the incoming URLs are routed between the edges
and the origin server. You can have a computer run Flash Media Server in a mixed mode, in
which certain virtual hosts on this system run applications locally, while others run
applications remotely.
To configure Flash Media Server, you edit or modify the XML tags in its configuration files.
Following are some representative examples:
■The Anonymous tag in the Vhost.xml file configures the edge server as either an implicit
(transparent) or explicit proxy.
For more information, see “Anonymous” in Managing Flash Media Server.
■The Mode tag in the Vhost.xml file configures Flash Media Server to run as an origin or
edge (proxy) server.
For more information, see “Mode” in Managing Flash Media Server.
■The LocalAddress tag in the Vhost.xml file allows the administrator to control the
network traffic by isolating incoming and outgoing traffic to separate network interfaces.
For more information, see “LocalAddress” in Managing Flash Media Server.
■The Scope tag in the Application.xml file determines the process scope in which to run
the application. Set this tag to run the applications and proxies in inst mode. Each
application and virtual host has its own process.
For more information, see “Scope” in Managing Flash Media Server.

Introducing edge servers 15
You can find examples of the configuration files, their tag structures, detailed information
about the tags, including cross references to associated tags, syntax, and examples in
Chapter 3, “Configuration Files” in Managing Flash Media Server.
Deploying a cluster of edge servers
You can also deploy a group of connected edge servers as a cluster. Each edge server in a cluster
can access the origin server. Clustering lets you distribute across the many edges in the cluster
all connections to applications that are running on the origin server. The origin server always
remains secure behind the edge servers.
For example, Organization A deploys a cluster of edge servers on its internal network. The
edge servers are defined as explicit proxies and dedicated to service specific users. When the
clients or users want to connect to the origin server, the client first connects to one of the edge
servers in the cluster. It is at this point where the connection requests are authorized or
rejected. If the request is valid, the edge server makes the connection to the origin server,
where the application is running. The origin server returns the results to the edge server,
which passes them on to the requesting client. The edge server also stores the results in a
cache, making it available to other servers and clients.
As this organization grows or reallocates its resources, it can add more edge servers to the
cluster or explicitly reassign clients to different edge servers.
Organization B uses a cluster of edge servers to manage the inbound traffic from clients
located outside of the network. This traffic is destined for Flash Media Server applications
running on the origin server. When these users try to connect to the origin server, a load
balancer positioned before the cluster routes the client’s request to one of the edge servers. The
edge server makes the connection to the origin server, where the application is running. The
clients remain unaware of the presence of the edge servers. The origin server returns the results
to the edge server, which in turn passes them to the requesting client. The edge server also
stores the results in a cache, making it available to the other external clients.
In this scenario, connections to applications are distributed across the many edge servers in
the cluster. If one edge server in the cluster cannot access an application, another edge in the
cluster handles the connection. Applications on the origin server are never directly exposed to
connection requests coming through the Internet.
This scenario describes how Organization B uses a reverse proxy to service incoming
connections instead of outgoing connection, as was the case in the Organization A scenario.

16 Using Edge and Origin Servers
Connecting to a cluster of edge servers
When edge servers are configured into a cluster, the clients probably do not know that edge
servers are present and servicing their connection requests. This is a secure and desirable
strategy for disguising the address of the origin server. A different scheme for connecting
clients to Flash Media Server is required.
With a cluster of proxies in place, when the client attempts to connect to Flash Media Server,
the call to the NetConnection.connect() method uses the User Datagram Protocol (UDP)
to initiate a local broadcast of an FPAD message. The other edge servers in the network that
receive the FPAD message respond to the client. The client automatically chooses the edge to
connect to. The edge then makes the connection to the origin server. This brief scenario
describes how a cluster of explicit proxies services outgoing connections to an origin server
Enrolling proxy servers in the cluster
Each proxy or edge in a cluster is dynamically assigned a numeric ID when it starts up. The
edge broadcasts a message announcing its presence. All edges in the cluster that are currently
running receive this message. Each edge responds with a message indicating its ID. The ID is
assigned from a sequence of numbers: 0, 1, 2, …, N-1, where N is the number of edges
allowed in the cluster.
The edge that is starting up waits for all of the responses to be received, then assigns itself the
first ID not found in the sequence. When an edge server shuts down, it broadcasts a message
announcing its exit from the cluster.
Accessing applications through an edge cluster
To maximize the conservation of network and bandwidth resources, Flash Media Server
directs to the same edge in a cluster all clients that request a connection to an application. All
the edge servers in the cluster automatically compute an affinity value based on the URI that
the client wishes to connect to. When a client broadcasts an auto discovery process message to
discover the available edges, an affinity value is returned in a message back to the client. After
the client receives responses from all of the currently active edges in the cluster, it
automatically selects the edge with the lowest affinity value to connect to.
The affinity value is dynamic; it adjusts to the increasing or decreasing workload of
connection requests and distributes the workload across edges in the cluster. For instance,
consider how the notion of affinity value applies in a cluster of three edges: edge0, edge1, and
edge2. As the workload on edge0 starts to peak, its connections start to spill over to edge1.
Both have a computed affinity value of 1. As edge1's load increases, its connections start to
spill over to edge2. Both have a computed affinity value of 2. As edge2's load increases, its
connections start to spill over back to edge0.

Introducing edge servers 17
When the load on an edge starts to scale down, so does its affinity value. Because the client
always looks to connect to the edge with the lowest affinity value, this edge begins to take
back connections that had spilled over into the next edge. The objective is to balance the
number of connection requests to the available resources, and have all connections to the same
application instance again pass through the same edge.
The client logic remains simple: to connect to the edge with the lowest affinity value. The
client only needs to know the affinity value for the different edges in the cluster to make the
connection to the right edge.
Clustering reverse proxies
Reverse proxies are configured to redirect incoming connection requests instead of outgoing
connection requests, as is the case with explicit and anonymous proxies. The client’s request to
connect to the desired application must first pass through the load balancer positioned before
the cluster of reverse proxies before it reaches the origin server. When reverse proxies are
deployed, the client's broadcast for a connection request cannot reach either an edge server or
the origin server and the requested application. The URI for the proxy cluster or the origin
server is not found on the client. Reverse proxying requires a different strategy for connecting
clients and applications.
Clustering works efficiently when all clients that request the same application instance
connect to the same edge server in the cluster, where the application is cached. To accomplish
this efficiency with reverse proxying requires a multistep procedure.
1. The client sends an HTTP request that includes an XML.load call to the origin server:
http://origin[:<port>]/fms/fpad?uri=<uri>
2. The load balancer on the remote network intercepts the request and routes it to one of the
edge servers in the cluster.
3. This edge server then acts as an FPAD client and broadcasts an FPAD message.
4. The edge servers enrolled in the cluster respond with their affinity values.
5. The broadcasting edge server chooses the edge server with the lowest affinity value.
6. This edge server sends the required information back to the client:
<?xml version=\"1.0\" encoding=\"utf-8\" ?>
<fpad>
<proxy>10.133.192.85:1935</proxy>
<timestamp>627539012</timestamp>
<userdata></userdata>
</fpad>
where the <proxy> tag contains the host:ip address of the edge server to connect to.

18 Using Edge and Origin Servers
7. The client then uses the information to make an explicit connection: first to the edge, then
to the origin server using a wrapped URI:
nc = new NetConnection();
nc.onStatus = function(info)
{
trace(info.code);
}
uri = "rtmp://yourcompany.com/app/inst";
myXML = new XML();
myXML.onLoad = function(success)
{
if (success)
{
var proxy = this.childNodes[1].childNodes[1].firstChild.nodeValue;
uri = "rtmp://" + proxy + "/?" + uri;
}
nc.connect(uri);
}
myXML.load("http://yourcompany.com/fcs/fpad?uri=" + uri);
The /fcs/fpad? code in the XML.load() URI tells the edge server that it needs to broadcast
an FPAD message using the URI named uri, as specified.
Setting up origin and proxy servers
Use the following guidelines as you install and configure the origin and proxy servers. Using
these guidelines helps ensure satisfactory performance and results:
■Make sure your Macromedia license permits you to use proxy servers or a proxy cluster.
■Deploy all proxy and origin servers on identical computers.
■Use the same operating system (Linux or Windows) on all computers to avoid conflicts
with filenames.
Linux uses case-sensitive filenames; filenames on Windows are case-insensitive.
■Install Flash Media Server on the first server.
■Configure this instance of Flash Media Server as an origin server.
■Install and configure Flash Media Server on all of the edge or proxy servers that your
license permits.
■Make sure the fms.ini file is customized on each origin and proxy.
The fms.ini file is machine-specific.
■Configure the origin server to listen on one port; you can configure proxies to listen on
one or multiple ports.
■Verify that all proxies can access the origin server.

Introducing edge servers 19
■Locate the origin server and those edge servers nearest to it on the same subnet.
■If you are licensed to deploy a cluster, make sure all proxies in the cluster are configured
identically.
■Configure the conf directory on one proxy.
■Place a copy of this conf directory in the same location on the other proxies.
■Use a load balancer when you deploy more than one proxy.
■Place the load balancer between the clients and the proxies.
■Configure the balancer to access the proxies in round-robin mode.
■Do not place the load balancer immediately before the origin server.
To set up a cluster of edge servers:
1. Install and configure the first Flash Media Server.
Use the same serial number and license file each time you install Flash Media Server.
2. Confirm that this Flash Media Server instance is working correctly.
3. Configure the Flash Media Server instance as an origin server.
4. Install and configure the next Flash Media Server in the cluster.
5. Configure this Flash Media Server instance as an edge server.
6. Make sure this edge server points to the origin server.
7. Repeat steps 5 through 7 for each edge server that your license file allows.
Your Flash Media Servers are now clustered. To expand the cluster’s capacity, you may add
new edge servers, if your license permits, to the cluster and configure them by following these
instructions.
Maintaining edge server clusters
When an edge starts up, it broadcasts its presence to all other edges in the cluster. When an
edge shuts down, it broadcasts that it is leaving the cluster. If an edge shuts down, all other
edges in the cluster detect the change in state because the edges no longer receive the keep-
alive messages from that edge. The remaining edges automatically update their views of the
cluster and remove the shut-down edge from their views. You only have to start and stop
edges, and they automatically determine which edges are currently enrolled in the cluster.
NOTE
A special cluster license file is required. For more information, contact your
Macromedia representative.

20 Using Edge and Origin Servers
Clearing the edge server cache
Macromedia recommends that you create a weekly scheduled task to clear the edge server
cache.
To create a scheduled cache clearance:
1. Create a cache.bat file to empty the cache directory.
The entry in the cache.bat file has the following syntax:
del /Q /S <cache_directory>\*.*
2. Run the cache.bat file and verify that it deletes files in the cache directory.
■Note that the directory structure remains; this is an expected behavior.
■Any files currently locked by the edge server are not deleted; this is also an expected
behavior.
3. Select Control Panel > Scheduled Tasks > Add Scheduled Task.
4. Select cache.bat as the new file to run.
Macromedia recommends that you schedule the task to run weekly during off hours, such
as early Sunday morning.
Replicate this procedure on each edge server.