Programming Flash Communication Server

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.