A Brief Overview of Jabber Server Scaling

Notes regarding diagram:

- Flow moves from the right.

- Red lines show the flow of message or other data destined from a client to a remote server.

User Hashing

For redirecting to slaves, the master server does a simple hash on the username to decide which slave that the user packets belong to.

If the user information (username, password, etc.) is held in a central database (LDAP, MySQL, etc.), then the master server can simply evenly distribute the user to the next slave in a distribution table. No server besides the central database server need know any details about a user before connection. This is somewhat analogous to a deck of cards being distributed to players in a card game. The dealer knows nothing about the cards (users), he simply passes them out evenly among the players (slaves).

If user information is stored on the slaves, then the master server distributes users based on some predefined ranges. Ranges might simply be defined by all users through A-G for slave1, all users H-L for slave 2 and so on. The master server simply looks up where the user fits in the ranges and redirects the client to connect to the appropriate slave.

Client Login

A client logins to the master server (e.g. @jabber.org). The master server does a hash on the username and other user data to decide which slave the client belongs to. It then sends an error 302 (redirect) back to the client as a response to the jabber:iq:auth. The master server also sends a new IP address (which is the IP address of one of the slaves) for the client to connect to within that same redirect packet. The client catches the IP address and starts the login procedure over again with the new address with the slave. The slave does the same hash that the master server did to make sure that the client is connecting to the right server. If it isn't the right server, then the slave does a jabber:iq:auth error 302 to send the client to the correct slave.

After finding the right server to authenticate to, the slave uses local XDB information (flat file, MySQL, LDAP, etc.) or a central server (MySQL, LDAP, etc.) to authenticate the user.

Remote Packets

When clients send remote packets (messages, subscription, presence, etc.), the slave masks the packets as from the master server. Thus, all the users on the slaves appear to be from one server (e.g. @jabber.org). When a packet comes in from a remote server, the go through the master server and then on to the correct slave. To determine the correct slave to send the packets to, the master server does the same hash as in the login proceedure to figure out which slave to forward the packet on to.