InstallGuide/Jabberd2Architecture
Go up: WikiStart
13. Jabberd 2 Architecture (Draft)
N Note: This Section Is Work in Progress
Note that this section is largely a work in process. Thus, information below should be regarded as draft documentation, and not as a finalized description of Jabberd 2 architecture. Essentially, I am adding to this section as I learn about Jabberd 2.
TODO: Add architecture introduction consisting of architecture feature list -or- just new feature list
13.1. Jabber Network Architecture
Jabber, in the form of the XMPP protocol, provides a protocol for messaging, and as such it provides a standardized platform for Jabber server communication:
- Jabber Client to Jabber Server
- Jabber Server to Jabber Server
- Jabber Server to Foreign IM Gateway
Figures 13.1 and 13.2 below demonstrate how these three types of communication can occur.
Figure 13.1.1. Jabber Deployment Diagram (High Level View)*:
PC 2 SVR 2 PC 3
.-----------------. .-----------------. .-----------------.
| | | | | |
| ,---------. | | ,---------. | | ,---------. |
| ,' `. | | ,' `. | | ,' `. |
|( Jabber Client -+-------+- Jabber Server -+-------+- Jabber Client )|
| `. ,' | | `. ,' | | `. ,' |
| `---------' | | `----+----' | | `---------' |
`-----------------' `--------+--------' `-----------------'
|
PC 1 |
.-----------------. .--------+--------.
| | | | | SVR 1
| ,---------. | | ,----+----. |
| ,' `. | | ,' `. |
|( Jabber Client -+-------+- Jabber Server )|
| `. ,' | | `. ,' |
| `---------' | | `----+----' |
`-----------------' | | |
| ,----+----. |
| ,' Foreign `. |
|( IM )|
| `. Gateway ,' |
| `----+----' |
`--------+--------'
|
|
.--------+--------. .-----------------.
| | | | |
| ,----+----. | | ,---------. |
| ,' Foreign `. | | ,' Foreign `. |
|( IM -+-------+- IM )|
| `. System ,' | | `. Client ,' |
| `---------' | | `---------' |
`-----------------' `-----------------'
SVR 3 PC 4
Figure 13.1. Adapted from XMPP Core Draft
Figure 13.1.2. Key to Deployment Diagrams:
Key for Deployment Diagrams
+--------------------------------------------+
| |
| +-------------+ TCP/IP Connection |
| |
| ,---------. |
| ,' `. |
| ( ) Software Package |
| `. ,' or Module |
| `---------' |
| |
| .---------------. |
| | | |
| | | Computer: |
| | | PC or Physical |
| | | Server |
| `---------------' |
| |
+--------------------------------------------+
13.1.1. Jabber Client to Jabber Server
In the diagram above, Jabber Clients on PC 2 and PC 3 are able to communicate via Jabber IM provided by SVR 2. Both clients have accounts on this server, and this part of the diagram, if taken by itself, would represent a closed or private Jabber system.
Note that a Jabber Client is not necessarily a user-based IM client. For example, the client running on PC 3 might actually be part of a web server. In this manner, a user on PC 1 might make updates to the web server by using a Jabber client.
13.1.2. Jabber Server to Jabber Server
Communication between SVR 1 and SVR 2 demonstrates how Jabber employs a distributed architecture. Clients on PC 1 and PC 2 are able to communicate with each other even though these clients have accounts on separate servers. These clients do not need to know anything about the remote servers. Instead, each client needs only to know the address of the client with which it wishes to communicate.
Jabber servers running on SVR 1 and SVR 2 rely on the Domain Name Service (DNS) for address lookup in order to communicate with each other. In this manner, the Jabber IM system resembles the email network architecture provided by POP and SMTP, the most widely used email protocols on the Internet. The ability to resolve names of other jabber servers and to route messaging makes jabber unlike proprietary IM systems. Jabber does not rely on a centralized server farm. Thus, Jabber is easily scalable, and it can be used as a closed or open system.
13.1.2. Jabber Server to Foreign IM Gateway
In this diagram, SVR 1 communicates with a Foreign IM Gateway running on the same machine. This gateway is able to communicate with a Foreign IM System, such as AOL, MSN, Yahoo or IRC. Connection with this communication gateway allows clients on PC 1 and PC 4 to communicate despite the fact that the user on PC 1 is running Jabber client software, while the user on PC 4 is running software, such as AIM, that uses a completely different messaging protocol.
The foreign IM example demonstrates the flexibility that Jabber provides. The XMPP protocols dictate set of XML-based communication standards. Therefore, a gateway for other protocols can be created, provided that the details of such a non-XMPP protocol are known.
13.2. Jabberd 2 Component Architecture
N Note: Subsequent Documentation is Jabberd 2 Specific The preceding section provides an overview of how the Jabber architecture works. Other Jabber servers, in addition to Jabberd 2, provide the same services. However, the documentation in the subsequent sections deals with Jabberd 2 specifically.
The beauty of the Jabberd 2 architecture lies in the fact that its component architecture distributes services across five components, each of which communicates over TCP/IP:
- Router
- Server to Server (S2S)
- Resolver
- Session Manager (SM)
- Client to Server (C2S)
Jabberd 2 also relies on third-party components:
- Application Data Store
- Authentication Data Store
- Foreign IM Gateway(s)
Figure 13.2 shows how these components communicate and how they are generally located on a single physical server.
Figure 13.2. Jabberd Deployment Diagram (Component Level View):
PC 1 SVR 2 SVR 3
.-----------------. .-----------------. .-----------------.
| | | | | |
| ,---------. | | ,---------. | | ,---------. |
| ,' `. | | ,' `. | | ,' Foreign `. |
|( Jabber Client )| |( Jabber Server )| |( IM )|
| `. ,' | | `. ,' | | `. System ,' |
| `----+----' | | `----+----' | | `----+----' |
`--------+--------' `--------+--------' `--------+--------'
| | |
| | |
.---------------------------------+----------------------+----------------------+----------.
| | | | |
| ,---------. ,----+----. ,----+----. | |
| ,'Authentica-`. ,' Client to `. ,' Server to `. | |
| ( tion Data +-----+ Server ) +--+ Server ) | |
| `. Package ,' `. (C2S) ,' | `. (S2S) ,' | |
| `---------' `----+----' | `---------' | |
| | | | |
| | | | |
| | | | |
| ,----+----. | ,---------. | |
| ,' `+----+ ,' `. | |
| ( Router +------+ Resolver ) | |
| `. +----+ `. ,' | |
| `----+----' | `---------' | |
| | | | |
| | | | |
| | | | |
| | | | |
| ,---------. ,----+----. | ,----+----. |
| ,'Application`. ,' Session `. | ,' Foreign `. |
| ( Data +-----+ Manager ) +-------------------------+ IM ) |
| `. Package ,' `. (SM) ,' `. Gateway ,' |
| `---------' `---------' `---------' |
`------------------------------------------------------------------------------------------'
SVR 1
N Note: Jabberd 2 Relies on External Packages
The diagram above shows all the components required for a functioning Jabberd 2 server in addition to one optional component, a Foreign IM Gateway. Foreign IM Gateways are not included with the Jabberd 2 distribution. Packages for authentication and application data are also not included with the Jabberd 2 Distribution. Instead, Jabberd 2 connects to third-party data and authentication packages that must be installed in order for Jabberd to function.
Figure 13.2.1 shows how Jabberd 2 distributes functions across five separate modules. Just as the data stores and gateway(s) may be located on separate machines, the Jabberd 2 components may be easily distributed across machines because each component consists of a configuration file and a binary executable that communicates via TCP/IP. This architecture allows the server to scale. When load on a Jabberd 2 server becomes high, component(s) can be moved to separate machines.
13.2.1. Router
The Router is the backbone of the Jabberd server. It accepts connections from Jabberd components and passes XML packets between components.
13.2.2. S2S
The S2S (Server to Server) component handles communications with external servers. S2S passes packets between other components and external servers, and it performs dialback to authenticate remote Jabber servers.
13.2.3. Resolver
The Resolver acts in support of the S2S component. The Resolver resolves hostnames for S2S as part of dialback authentication.
13.2.4. SM
The SM (Session Manager) component implements the bulk of the instant messaging features:
- Message passing
- Presence
- Rosters
- Subscriptions
The SM component connects to the "Application Data Package (db) in order to provide persistant data storage. Additionally, the SM component handles the Jabber extensions of disco (discovery) and privacy lists*.
13.2.5. C2S
The C2S (Client to Server) component handles communication with Jabber clients:
- Connects to Jabber clients
- Passes packets to the SM
- Authenticates clients
- Registers users
- Triggers activity with the SM
The C2S component connects to the Authentication Data Package (authreg) in order to register and authenticate users.
13.3. Jabberd 2 Module Decomposition
TODO: Section TBD
13.4. Jabberd 2 Data Handling
Jabberd employs data handling that allows for mapping to various data packages. The concept of a collection object lies at the core of Jabberd data handling. Each collection object has the attributes of type and owner. Type specifies what category of data is being handled, such as queue, vcard or roster-items. Owner specifies who owns the collection. For user-related data, Owner is a jabber ID (JID).
Each collection holds one or more data objects. Each of these data objects is a tuple consisting of a key, value and type. Key is a string that specifies the kind of data being held. Value is the data being held, and type is the is the data type, i.e. Boolean, integer, string, etc. The diagram below shows how these objects are related.
Figure 13.4. Jabberd Data Objects:
+--------------+
| Collection |
+--------------+---+
| Collection | |
+--------------+---+ |
| Collection | | | Key for Object Diagram
+--------------+ | | +-------------------------------------+
| Type | |---+ | |
| Owner | | | +-------+ |
| |---+ | | | |
| | | +-------+ Object |
+--------------+ | | | |
| | | | |
| | +-------+ |
| | | |
| | | One-to-Many Relationship |
^ | | |
+-------------------+ | ^ |
| Collection Data | | |
+-------------------+ +-------------------------------------+
| Key |
| Value |
| Type |
| |
+-------------------+
3.5. Jabberd 2 Data Structure (for MySQL)
Jabberd Data handling becomes clearer as we see it applied to the MySQL data package. In the relational world, each collection type becomes a table, and each collection data key becomes a table field. Thus, each row consists of a collection owner (JID) plus one or more data fields.
13.5.1 Table List (for MySQL).
The following is a list of MySQL tables for a deployment that uses Jabberd for both its authentication and its application data package (authreg and db, respectively):
active
Stores date/time upon which each account first became active.
authreg
Contains authentication information, including username, realm and password.
disco-items
Stores persistent discovery information so that it is available for offline retrieval.
logout
Stores JID and timestamp for most recent user log out.
motd-message
Stores message of the day (MOTD) in XML format.
motd-times
Records JID's and timestamps for receipt of MOTD.
privacy-default
Stores the name of the current list in use for a user so it can be made active on startup.
privacy-items
Stores user privacy lists (blacklists/whitelists).
private
Provides private XML storage for uses such as user preferences or bookmarks.
queue
Stores queued messages in XML format.
roster-groups
Stores user roster items only for those roster items that have an assigned group.
roster-items
Stores user roster items, including authorization status.
vacation-settings
Handles vacation settings, including start, end and message.
vcard
Stores vcard information.
Each of the above tables represents a collection type in Jabberd. Note that the authreg table handles the authentication aspect for Jabberd when MySQL is used as the authentication data package.
13.5.2. Table Descriptions (for MySQL).
Descriptions for the Jabberd tables (as they exist in MySQL) appear in the diagram below:
Figure 13.5.2. Jabberd Table Descriptions:
MySQL Table Descriptions +------------------------------------------------------------------------------------------------------------+ | | | +-------------------------------+ +-----------------------+ +------------------------------+ | | | active | | authreg | | disco-items | | | +-------------------------------+ +-----------------------+ +------------------------------+ | | | | | | | | | | +-------------------------------+ +-----------------------+ +------------------------------+ | | | collection-owner: TEXT | | username: TINYTEXT | | collection-owner: TEXT | | | | object-sequence: BIGINT(20) | | realm: TINYTEXT | | object-sequence: BIGINT(20) | | | | time: INTEGER(11) | | password: TINYTEXT | | jid: TEXT | | | | | | token: VARCHAR(10) | | name: TEXT | | | +-------------------------------+ | sequence: INTEGER(11) | | node: TEXT | | | | | | hash: VARCHAR(40) | | | | | +-------------------------------+ | | +------------------------------+ | | +-----------------------+ | | | | | | +------------------------------+ | | +-----------------------+ | | | | | | +-------------------------------+ +------------------------------+ +-------------------------------+ | | | logout | | motd-message | | motd-times | | | +-------------------------------+ +------------------------------+ +-------------------------------+ | | | | | | | | | | +-------------------------------+ +------------------------------+ +-------------------------------+ | | | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | | | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | | | time: INTEGER(11) | | xml: TEXT | | time: INTEGER(11) | | | | | | | | | | | +-------------------------------+ +------------------------------+ +-------------------------------+ | | | | | | | | | | +-------------------------------+ +------------------------------+ +-------------------------------+ | | | | | | +------------------------------+ +-------------------------------+ +------------------------------+ | | | privacy-default | | privacy-items | | private | | | +------------------------------+ +-------------------------------+ +------------------------------+ | | | | | | | | | | +------------------------------+ +-------------------------------+ +------------------------------+ | | | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | | | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | | | default: TEXT | | list: TEXT | | ns: TEXT | | | | | | type: TEXT | | xml: TEXT | | | +------------------------------+ | value: TEXT | | | | | | | | deny: TINYTEXT(4) | +------------------------------+ | | +------------------------------+ | order: INTEGER(11) | | | | | | block: INTEGER(11) | +------------------------------+ | | | | | | +-------------------------------+ | | | | | | +-------------------------------+ | | | | | | +------------------------------+ +------------------------------+ +-------------------------------+ | | | queue | | roster-groups | | roster-items | | | +------------------------------+ +------------------------------+ +-------------------------------+ | | | | | | | | | | +------------------------------+ +------------------------------+ +-------------------------------+ | | | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | | | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | | | xml: TEXT | | jid: TEXT | | jid: TEXT | | | | | | group: TEXT | | name: TEXT | | | +------------------------------+ | | | to: TINYTEXT(4) | | | | | +------------------------------+ | from: TINYTEXT(4) | | | +------------------------------+ | | | ask: INTEGER(11) | | | +------------------------------+ | | | | +-------------------------------+ | | | | | | +-------------------------------+ | | | | | | +-------------------------------+ +------------------------------+ | | | vacation-settings | | vcard | | | +-------------------------------+ +------------------------------+ | | | | | | | | +-------------------------------+ +------------------------------+ | | | collection-owner: TEXT | | collection-owner: TEXT | | | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | | | start: INTEGER(11) | | fn: TEXT | | | | end: INTEGER(11) | | nickname: TEXT | | | | message: TEXT | | url: TEXT | | | | | | tel: TEXT | | | +-------------------------------+ | email: TEXT | | | | | | title: TEXT | | | +-------------------------------+ | role: TEXT | | | | bday: TEXT | | | | desc: TEXT | | | | n-given: TEXT | | | | n-family: TEXT | | | | adr-street: TEXT | | | | adr-extadd: TEXT | | | | adr-locality: TEXT | | | | adr-region: TEXT | | | | adr-pcode: TEXT | | | | adr-country: TEXT | | | | org-orgname: TEXT | | | | org-orgunit: TEXT | | | | | | | +------------------------------+ | | | | | | +------------------------------+ | | | +------------------------------------------------------------------------------------------------------------+
© 2003 Will Kamishlian and Robert Norris
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
