This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
Conclusion
|
695
it left off. If a live stream is being played, it just begins playing the stream at its cur-
rent location as soon as the connection is established. Similar strategies can be used
with conference rooms, but they require a little more care.
When a conference room is allocated on a single-leaf server, a fallback RTMP
address on another FlashCom Server can also be allocated. If the instance goes down
for some reason, clients connected to it can automatically attempt to connect to the
alternate instance. If each FlashCom Server is connected to a centralized filesystem
and has an identical FlashCom installation on it with the same drive mappings (or
same mount points), the alternate instance can read the same files, including shared
objects and streams that were available to the original. However, under no circum-
stances can two instances be allowed to access the same shared object files or update
the same stream files at the same time. In other words, either all the clients are dis-
connected from the original instance and connected to the alternate instance or none
should be moved. When an instance or entire server goes down, the client’s NetCon-
nection object will eventually receive an information object with a
code value of “Net-
Connection.Connect.Closed”. Unfortunately, such a code can also mean that the
client’s network connection was dropped temporarily and that many other clients
are still happily connected to the instance. So when a client loses a connection to an
instance before a meeting is over, it should attempt to contact the same instance
again before trying the alternative server. To avoid any possibility of clients ending
up in separate instances, the alternative instance can attempt to contact the original
instance and refuse the client access if the latter is still available. This level of interin-
stance coordination requires careful planning and coding.
When multiple lobbies are using one master instance, failure of a lobby may be easy
to handle. The client simply reconnects to another lobby on another server. How-
ever, if a master instance goes down, an alternative must be available that can start
up and take over. The new master will have to re-create the state of the old master by
asking each lobby to update it. Keeping a master instance and another instance in
sync so that the other can take over as the master without having to rebuild its state
is difficult because a proxied shared object cannot simply be promoted to become a
master shared object. One scheme is to use persistent shared objects that are fre-
quently flushed to disk by the master instance. The shared objects are stored on a
separate storage file server. If a master server fails, a new master is allocated and
reads the persistent shared object from the storage file server. Another scheme is to
replicate updates by sending every shared object slot change from the master
instance to a shadow copy of the master instance. If the master instance fails, the
shadow copy becomes the master instance.
Conclusion
Just as there are different types of FlashCom applications, there are different
approaches to building multi-instance applications that are scalable and
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
696
|
Chapter 16: Building Scalable Applications
fault-tolerant. Media-on-demand, live one-way broadcasting, and n-way communica-
tion applications all provide different challenges. Applications that require real-time
instance coordination are more challenging to design and build than those that do
not. Component-based applications are a good way to partition multi-instance appli-
cations. The components introduced in Chapters 13 through 15 have client- and
server-side parts that work together. In a multi-instance application, a good practice
is to further divide components so that their server-side parts know how to commu-
nicate with one another. In a simple broadcast tree, a stream list component might
have four parts—one each for a source client, root server, leaf server, and destina-
tion client. Writing each part of the component separately simplifies multi-instance
development.
This chapter has dealt with building multi-instance and multiserver applications that
don’t bog down as the number of client connections increases. Unfortunately, add-
ing instances and servers won’t help application performance over slow network
connections. The next chapter describes what you can do to provide a good applica-
tion experience despite network limitations.

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.