Sun Java System Instant Messaging 7.2 Administration Guide

Instant Messaging User Partitioning Algorithm

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:

  1. 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.

  2. 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.

  3. 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.


Example 7–1 Instant Messaging Redirect Sequence of Events

This example describes the sequence of events that occur for a successful client redirect to take place.

  1. Administrator runs rdadmin to generate and/or update the redirect database.

  2. User connects to the redirect server and attempts to authenticate.

  3. Redirect server determines the identity of the user and looks up the corresponding user ID in the redirect database.

  4. 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.

  5. Redirect server determines the node to which the user will be redirected based on the assigned partition ID.

  6. 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.

  7. The client interprets the error and establishes a connection to the node returned with the error.

  8. Redirect server continuously monitors nodes and updates its partition-to-host table as required.