The Adaptor

You can think of a server adaptor as similar to a domain in a traditional network. It is an isolation of users and hosts and has its own security context. In essence, consider the adaptor as a branch of the server tree. Communication Server applications exist within adaptor virtual hosts, as described in the previous section.

Each adaptor on a server must operate on a different IP address, domain, or port number. For example, the default adaptor communicates on port 1935. A second adaptor that is bound to the same IP address must be assigned to communicate on an alternate port number. Appropriate action on any network firewalls must also be taken so that other ports and IP address can be seen by the intended audience.


Adaptors are defined with two steps. First, a folder must be created in the server's conf folder (located in the folder where the server was installed). Second, the adaptor must be defined in the Server.xml file. Each adaptor folder must contain a series of elements, including an Adaptor.xml configuration file and a default virtual host folder with its configuration files (Application.xml and Vhost.xml). You will see more on the virtual hosts soon. For now, take a look a the configuration file for adaptors.

Configuration: Adaptor.xml

The Adaptor.xml file is the only file required in the Adaptor folder. This file contains the adaptor settings and is read by the server on reboot. It is an important file to manage the communication port, server resources, and security parameters for a collection of virtual hosts. It has no user context, as the users are defined in the virtual host or the server. It operates as a child under the limitations declared in the Server.xml file. Listing 14.1 shows the default Adaptor.xml document:

Listing 14.1 The default Adaptor.xml document


Adaptor security provides domain access context for virtual hosts. It operates under the security context provided by the Server.xml file with the ability to restrict and allow administrator access by domain. The <MaxThreads> node can provide a significant resistance to denial of service attacks by lowering the number of threads, which reduces the amount of CPU processing used by all hosts in the adaptor. It is also a good idea to reduce this number during development, so renegade applications don't bring your server to its knees. Remember, if you have multiple adaptors on a single server, change the <HostPort> node.

    Part I: 10 Quick Steps for Getting Started