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

Get Programming Flash Communication Server now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.