The redirect server is an Instant Messaging server instance configured specifically to perform redirect tasks such as assigning connection end-points to Instant Messaging servers. Adding a redirect server to your deployment reduces the amount of communication between servers by grouping users who are likely to communicate with each other on the same host. This reduces the amount of presence notifications sent back and forth between servers in your deployment. Groups of users are determined by contact list contents. Shared entries in contact lists indicate a higher likelihood for communication.
Instant Messaging determines the best division between users in your deployment and creates groups or partitions of users. The algorithm Instant Messaging uses is as follows:
Determine one or more sets of users, or user network, and their connections in your deployment. The redirect server then creates a table called the user-to-network map that maps each user to a user network.
Partition user networks that are larger than the maximum partition size along weakest ties, such that the maximum size of each weakly connected component is no larger than the configured partition size. Weak ties may be determined by a low number of connections between user networks, however, other parameters such as geographic constraints, number of connections per user network, and other constraints set by administrators may also be taken into account when partitioning user networks.
Distribute the sets into a specified number of partitions of roughly equal size. The redirect server first creates the network-to-partition table as part of this process and finally the user-to-partition table. These tables together make up the redirect database. The redirect database maps each user with a partition ID. You create and manage this database using the rdadmin command line utility.
This example describes the sequence of events that occur for a successful client redirect to take place.
Administrator runs rdadmin to generate and/or update the redirect database.
User connects to the redirect server and attempts to authenticate.
Redirect server determines the identity of the user and looks up the corresponding user ID in the redirect database.
If the redirect server does not find the user ID in the redirect database, the redirect server contacts the next redirect server (determined by a round-robin mechanism) to locate the redirect database that contains the user ID. If the user ID is found in the redirect database, the redirect server obtains the partition ID to which the user has been assigned.
Redirect server determines the node to which the user will be redirected based on the assigned partition ID.
Redirect server returns an error to the client that contains the node to which it is being redirected and closes the connection to the client.
The redirect server uses the see-other-host stream error to return this information to the client. See RFC 3920 for more information.
The client interprets the error and establishes a connection to the node returned with the error.
Redirect server continuously monitors nodes and updates its partition-to-host table as required.
The database includes only local users. Gateways, components, and remote users are not included in the redirect database.
The redirect server is an instance of the Instant Messaging server whose sole function is to redirect client connections. The redirect server does not perform any other service to end users. Upon startup, the redirect server loads the server configuration and partitions file and creates the following data structures:
A list of instances to which this server can redirect client connections. This is the redirect server's instance list. The instance list is built from entries in the redirect.hosts file.
A table that maps partitions to physical hosts. This table is called the partition map. The redirect server builds the partition map by going through the instance list until it reaches the specified maximum number of partitions.
The redirect server uses both data structures to redirect client connections. See Example 7–1 for an explanation of how the redirect server uses this information.
As much of the StartTLS negotiation as is required to establish the identity of the connecting client may take place between the client and the redirect server. The client does not need to verify credentials, instead it only requires the user ID.