The Virtual Host

If isolating applications is important to you, then virtual hosts should handle most operations. If you have multiple developers working on a single Flash Communication Server, then creating virtual hosts is what you need. Virtual hosts are collections of applications and exist under the limitations defined by the adaptor. Virtual hosts are important to ensure the security of independent applications. They are also important to limit applications from consuming 100% of bandwidth and user resources on a particular license of the server. The virtual host configuration file contains many security provisions that ensure applications and users don't overload the server and deny service for other applications.

Consider virtual hosts as "virtual directories" in the context of a web server. The virtual host can also have multiple alias names on the adaptor.


Virtual host users are defined by the administrator in the Server.xml file. You can add, remove, or edit user passwords using the Administration Console. Virtual host administrators can use the Administration Console to add, remove, or edit user passwords only within the virtual host to which they have been assigned. User accounts cannot belong to more than one virtual host. The primary reason for virtual host users is to access the App Inspector during deployment or development procedures.


Virtual hosts require two sets of folders. First, the configuration folder exists within the adaptor folder in the server's conf folder. The configuration folder contains the Vhost.xml configuration file.

The application folder does not exist within the conf folder for security reasons. The application folder contains the collection of ASC, FLV, and FSO files used by the application. It is a good idea to keep them separate. This folder can exist anywhere on the file system. The developer install of Flash Communication Server places the default applications folder within the flashCom/applications folder, which is where you have been building the exercises in this book. If the server had a web server installed prior to installing Flash Communication Server, the applications folder is placed within the web server's root inetpub/wwwroot/ folder. The application folder can be changed by editing the <AppsDir> node in the Vhost.xml configuration file. You will be required to restart the virtual host when this file is changed.

Each virtual host must have an admin folder in the root of the application folder. This folder is required for the App Inspector and the Administration Console to access the virtual host.

Configuration: Vhost.xml

The Vhost.xml file exists in the root of the virtual host's conf folder. The file provides ultimate control over all applications that are served from it. The <ResourceLimits> node defines limitations of connections, instances, streams, and SharedObjects. It also defines the location of the applications folder in the <AppsDir> tag.

The <Streams> node allows you to define a common location for all stream (FLV) files on the server. You can alias this simply by separating the alias name with the real file path. For example:


This reference will be available for each application running within the virtual host. Listing 14.2 shows the default Vhost.xml file, including some omissions from the Flash Communication Server manual.

Listing 14.2 The default Vhost.xml file


The <ApplicationInstanceGC> node was omitted from the Flash Communication Server Manual. The value within this node specifies, in minutes, how long an inactive application instance's resources will persist.


Access security in the virtual host is controlled by the adaptor. The <ResourceLimits> node, however, allows the server administrator to set limits on bandwidth and users, among others. This is a very important control, because it directly relates to your license. If this isn't set properly, an application could potentially consume the entire server license of users and bandwidth. The <Allow> node allows you limit access to the applications from certain trusted domains.

    Part I: 10 Quick Steps for Getting Started