Programming Flash Communication Server

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

694

|

Chapter 16: Building Scalable Applications

exceeds the server’s capacity. In practice, n-way applications rarely send more than

six simultaneous video streams to each client.

Let’s return to the application illustrated in Figure 16-2 and assume that an applica-

tion has to maintain lobby and room instances spread across multiple servers. When-

ever a client connects to a lobby, a slot in the master instance’s

activeUsers shared

object is updated with the client’s location and time of arrival. Every client has an

ActiveChatUsers component that shows every user connected to the application. As

already mentioned, this scheme is scalable only up to a point. A user will not want to

scroll through thousands of usernames to find someone. Worse, each added slot in

the

activeUsers shared object takes up memory in the master instance and in every

proxied shared object in the leaf instances. At some point, memory consumption will

incapacitate the servers.

The solution is to redesign the application so that it shows only a subset of clients to

each user while still maintaining information about what clients are connected. The

master instance can be replaced with a database server. Lobby instances in each leaf

server will poll a database for information in the friend list of the clients connected to

it. The database replaces the master instance. Polling—which is not an ideal solu-

tion—must be used in FlashCom 1.5.2 and earlier because Flash Remoting is a

request/response protocol.

Another complexity in the lobbies/rooms application is that while a client could, in

theory, connect to any lobby on any server, it must connect to the correct instance

on one server in order to participate in a room. Rooms are single instances and are

not necessarily spread across servers. In that case, each client must connect directly

to a particular leaf server.

By default, hardware load-balancing devices usually hide the IP address of the real

servers they are load balancing. For applications in which clients must connect

directly to an individual host, the IP address of each server must be directly reach-

able. If your hardware load balancer does not support direct access, software-based

load balancing should be implemented instead.

Redundancy and Failover

Servers, firewalls, packet shapers, and networks are all capable of failing to work

when your clients are using them. Few clients are really happy about coming back

later when the problem is fixed. To increase the probability that a client can con-

tinue working, redundant servers, firewalls, and network connections can be pro-

vided so that the client can reconnect—or fail over—to the redundant hardware.

Providing redundancy and failover for n-way FlashCom applications presents some

special challenges. In a one-way application, if a client loses a connection to a server

and cannot reestablish it, it simply tries to connect to another server. If it is playing a

recorded stream, it can play the same stream from another server and seek to where