Jabber Technical Profile
Overview of the overall framework of Jabber Instant Communication System Services
1, Jabber Technology Overview
This document includes the following:
Introduction Introduction
Foundations Basic Knowledge
High-Level Server Architecture High Order Service System
• Basic Message Flow basic information flow
? Authentication appraisal
? Jabber Session Manager Jabber Session Management
? Threading thread
Deliver Logic Send Logic
? Transport transmitter
? Subscriptions subscription
? Jabber ids
? Server Dialback service
? Conclusion Conclusion
? CopyRight Information copyright information
Introduction to Introduction
The first application of Jabber technology is a real-time system that initiates and leads the instant messages that have been led by an open source community. The Jabber Instant Message (IM) system and existing IM services are compared by the following key features:
? XML-based
? Distributed network
? Open protocol and kernel code
? Modular, scalable system architecture
This document provides a high-order overview of the Jabber system architecture, mainly introducing the design of the Jabber Open source server, and the current version is 1.4 (translation: The latest version is 2.0). For related information about the XML protocol of Jabber, see the Jabber Protocol Overview Reference document (http://docs.jabber.org/general/html/protocol.html).
(Note: This document integrates the following file content: Jeremie Miller
1999
Year 11
Monthly
day
"Jabber System Architecture Overview", Peter Millard
2000
year
4
month
25
day
About this document Previous version, Peter Saint-Andre
2000
Year 11
Monthly
day
"Jabber White Paper"
1.2. Foundations Basics
Jabber has a large extent to the most successful message system on the Internet: ie email. Such JabBer can provide communication on a distributed network that uses a common protocol, connecting to this network client, can send messages to the same server or other Internet using the received message. However, although Email is a storage-forwarding system, Jabber forwarding messages are real-time because Jabber servers (along with all other Jabber servers) know when a user is online. This ability is online and the core of instant messaging. Jabber provides these IM standard features through two additional features, which also makes Jabber different. The first is an open protocol that allows synergistic jobs between messaging systems. Second, it is a powerful root of XML, which makes communication between the two people, even between the application software.
Each of the above functions will be further set forth below and further expand the content of this document.
1.2.1. Client / Server client / server
Jabber uses a client-server system architecture instead of other instant messaging systems used by the client-client system architecture. All Jabber messages and data from one client to another must pass the server. Any client can be disclosed with another client to freely establish a direct connection, but these connections are only available for special service. Some instances are encouraged to build this connection, such as file transfer, but these instances must be negotiated through a client-server situation before they can be established. 1.2.2. Distributed Network Distributed Network
The Jabber's network system is imitating E-mail systematically. Each user has its own local server and receives information, messages, and online information on the server. You can add any number of Jabber servers that accept the client's connection and communicate with other Jabber servers. Each Jabber server is independent of other Jabber servers and has its own list of users. Through Internet, any Jabber server can call other Jabber servers. Each user corresponds to a special server (providing a service provider or administrative business) that provides registration services or administrative enterprises, such as: Stpeter@jabber.org (hereinafter, the Jabber ID section will be introduced) More information about the Jabber address).
1.2.3. Modular Server modular server side
The Jabber server follows two main rules:
? Monitor client connections and communicate directly with client applications
? Communication with other Jabber servers
The JABBER open source server is designed to modular, consisting of different code packages, which handle similar user authentication, data storage (offline messages, rosters, user information, etc.). In addition, the server can be extended by additional services, such as a complete security policy, allowing the server components to be connected or client selection to connect to the gateways of other messages.
A modular example is an independent "Transport" (transmitter) translated into other protocols through Jabber XML, which enables communication between the Jabber message system and the non-Jabber message system to communicate with online information. These transmitters are not a server kernel. Instead, they are easy to add to the server kernel server-side program, providing a more powerful functional service for end users.
1.2.4. Simple Client simple client
One design standard for the Jabber system is to support simple clients (as simple as the Telnet connection). In fact, the Jabber system architecture only has few limited restrictions on the client. The features that a Jabber client must support are:
• Communication with the Jabber server via TCP socket
? Analytical organization good XML packet
• Understand the message data type
Jabber transfer complexity from the client to the server side. This makes the client writing very easily (an evidence is that today's variety of clients), the update system function is also easy (so, there is no to force users to download new clients). The JABBER client communicates with the server through XML 5222 or more ports in TCP socket without providing communication between clients. In practical applications, many low-order client functions (such as parsing XML, understanding basic Jabber XML languages like
XML is the core part of the Jabber system architecture. Its most important role is the underlying scalability of the system and can express almost any structured data. (In particular, Jabber uses XML data streams to perform client-server-side communication. The server-side communication. XML data stream is generally initiated by the client to the server, the effective time of the XML data stream is directly related to the user's online session Associated.)
Jabber strictly abides by XML while do not need to know any information about information forwarding intermediary: No inherent provisions for information forwarding intermediaries, no need for system architecture of information forwarding intermediary. This is possible, in another aspect, this also enables the implementation of the transmitter that provides information transmitted with third-party services (such as: IRC, ICQ, AIM). Inside the Jabber system, like each of the other components in the Jabber system, the transmitter uses XML voice. More information about the Jabber XML protocol can be in the Jabber Protocol Overview (http://docs.jabber.org/general/html/protocol.html).
1.3. High-Level Server Architecture Higher Order Server System Architecture
The JABBER server consists of several components that are logically independent in the Jabber system, respectively. The server's kernel is a forwarding component, the unique function of this component is to communicate XML parsing from one basic component to another. There are four such basic components: receiving, connection, execution, and loading. These basic components parse the incoming XML forward to other basic components, and enable the downstream components of the basic components to use XML. Here is a demographic diagram of a high-order system architecture:
After a server is launched, the Jabber server is responsible for registering the component to perform its functional unit (?) Through the primary program of Jabber (as defined in the server's configuration file), and run the packet consisting of these functional units (with this To define all the delivery logic of all packets). The core of the JABBER server includes components that process the following public tasks:
• Session Management
• Client-server communication
• Server - server communication
? DNS solution
? User Authentication
? User registration
? Database query
• Store information for offline users
? Store and find VCARDS
• Filter information is set according to user
Group Chat (Multi-to-many communication)
? System log
In addition, the server kernel can supplement the "Transmitter", which is designed to solve other protocols different from the XML format of Jabber. (See the Transmitter section for details). These transmitters can naturally be present as a built-in component of the overall server system architecture. The current translation function is mainly for the following protocols:
? AOL Instant Messenger (AIM)
? ICQ
? Internet relay chat (IRC)
? MSN Messenger
Rich Site Summary (RSS 0.9)
Yahoo! Messenger
(Note: Additional transmitters can be added to Jabber as needed, such as in order to solve the IM uniform format, but the future transmitter is not elaborated in this document.)
1.4. Basic Message Flow basic message flow
For learning Jabber systems, research through the server's typical data flow is a good gentle way. (When the "message" element of XML refers to one of the three main elements specified in the Jabber open XML protocol, it can also reflect the core intent of the Jabber: Point-to-point transmission by using XML.)
Below is a chart for this data process:
The Jabber server (Simplified to "jabberd" in the above chart is originally "Jabber Daemon [Jabber Barber])) The encrypted" message "in the context of the user session on the host, under normal circumstances, The body can be generated by a direct TCP socket by a 5223 port if SSL is allowed and running. If the session does not exist, Jabberd will initiate an authentication process, which will be introduced in the following care section. If the session exists, the message package will be sent to the JABBER session management component ("JSM").
Here is an example of XML:
To='psaintandre@aim.jabber.org ' TYPE = 'Chat'>
Next, the JSM looks for the host name of the target server based on the server list on the internal configuration file of the Jabber server. Typically, the host name will be defined; for example, the configuration file on the Jabber.com server is defined in the Jabber.com server (the transmitter may be on a single machine). If the hostname is not defined in the configuration file, the "DNSRV" component will correspond to an IP address and port of this host. In addition, since the host has problems, the message package will be sent to the server to the server (S2S) component, in this example, jabber.org. The server to the server component will be passed directly from the specified external Jabber server (such as jabber.org) or the last transmitter on the host. In the above example, the message package is intended to pass an address on the AIM.jabber.org, so this package will be sent to the AIM transmitter on the jabber.org, then send it to an AOL Instant Messenger account (see below The transmitter portion). In another aspect, the final result is a message flows from a Jabber client through a Jabber server to another Jabber server or an external IM system. 1.5. Authentication certification
In the basic message flow, the message and online information are sent to the jabber in the context of one user session on a running host on a Jabber server. In the Jabber protocol, this session is kept by two XML flows, one is from the client to the server, and the other is from the server to the client. Below is an XML display of a session:
Send: Send: to = 'jabber.org' Send: XMLns = 'Jabber: Client' Send: XMLns: stream = 'http: //etherx.jabber.org/streams'> Recv: Recv: Xmls: stream = 'http: //etherx.jabber.org/streams' Recv: id = '39aba7d 2' RECV: XMLns = 'Jabber: Client' Recv: from = 'jabber.org'> Send: TYPE = 'set'> Send: Send: Send: Send: Send: Send: Recv: TYPE = 'result' /> (XML for User Session Goes Here) Send: Recv: In order to establish a session to build a server, you must first authenticate the user. The following chart shows the authentication activities: When the client is connected to the host and initiate an XML stream, the authentication process begins. The Jabber server will immediately query the 'IQ' (INFO / Query "type and the 'Query' subtype of the IQ: Auth 'in the namespace of' Jabber: IQ: Auth ', which contains authentication information for the user. The authentication information must contain a username and a plain text password (very obvious, this is a depressed), an use of the SHA1 algorithm (this default authentication is a "digital authentication") encrypted password, or some of the zero-disc certification The data. Once the authentication information is received, the XML interpreter sends a control command to the "Transfer" component of the Jabber server, which will cache XML sent from the client until the authentication result is sent. The host (usually, but not all in JSM form) will send the authentication package to the 'xdb' component of the Jabber server. The XDB component ('xdb', "XML Data Base" - XML base data) will send the authentication package to any subcomponents that register the authentication package type: For example, the apparent authentication package may pass the XML file in the file system. Used for 'xbd_file' subcomponents, while digital authentication packages are used to check LDAP for the 'xdb_ldap' subcomponent. The transfer component does not perform any processing to transmit the authentication package to the XDB component, and the XDB component will send the authentication package to the appropriate subcomponent. In addition, in order to improve performance, the XDB_LDAP component has its independent thread pool, which operates similar to the thread mode in the session manager. The XDB component returns the result of the authentication query to the host (also, usually JSM). If the authentication fails, the server returns the error code 401 to the client without initiating a session. If the authentication is successful, the JSM will turn on a session (if necessary will release the XML cache), all online information, messages, and IQ basic information in the context of the user session, until the client or server is sent by sending a shutdown data Status of the stream of streams. 1.6. Jabber Session Manager Jabber Session Manager Below is the activity process of the Jabber Session Manager: As mentioned earlier, the Jabber Session Manager component (JSM) handles various types of packets: message type, online information type, querying the initiator of a Jabber host or a servant's Jabber user information. At the same time, JSM also handles packets for offline users. For example, although I am not online, you still have a message to me through my Jabber ID (STPETER@jabber.org). JSM will properly handle this message, which is likely to be saved to I am again online. JSM finds the "resource" element from the XML (so-called "resource" means the location of the device, the client, my connection; may be "laptop", "gabber", "home" to determine if the user is online . Typically, if a packet does not include a resource element, it indicates that the user is not online. However, sometimes the resource element will be lost due to the wrong, so JSM will send a message package to "Offline" components, "Offline" components may be saved after the user is really offline, and the "offline" component may save the message or retrieve a vcard. . If the user is online, the message, the online information, the IQ packet is no longer sent to offline components, but is processed by JSM. In fact, any one will only have one to two possible states: either it is forwarded to the user, or it is sent by the user. Therefore, JSM opens two listening, one is "to", one is "from" and routes them into the module specified in the Jabber server. Once the module is specified, the encapsulation will be sent back to the monitoring program for processing after more modules. If all processing is complete, the encapsulation will send to a message source or message destination. The following example will help understand. I received a message from foobar@jabber.org. I am online, so the message is prepared for JSM. "To listening" monitors that there is a package that is sent to me, so I will issue a request to the JSM that has been registered. The first response module is MOD_FILTER, which is sorted by the criteria specified by the user. In this example (I seem to have never criticized it from our friends foobar), I configure MOD_FILTER to send all messages sent from foobar@jabber.org to my mailbox via the SMTP transmitter. We said that mod_filter reformats the message so that the specified receiver now replaces the original Jabber.org by SMTP.jabber.org, then send the encapsulation back to "To listener". Another call for the registered component, there is no response, so the encapsulation is sent to STPETER@smtp.jabber.org so that the package directly into my email address. It is necessary to focusing that this process is repeated, so many modules can process the encapsulation before the encapsulation is completed or from the user action. This makes JSM have great elasticity and scalability, as this can easily add new modules without any changes to the JSM original module (only need to be modified accordingly). 1.7. Threading thread The Jabber Session Manager improves performance via thread. When the service starts, a certain number of threads are assigned to the thread pool (the actual number is determined by the configuration file). When the load component feedback message package for the system is given to the session manager, the session manager dynamically removes the thread that is not used from the thread pool, assisted them to the message port, which is queued by the package (a "message Port "indicates a data structure that supports a client connection). If there is no available thread in the thread pool, the session manager may (but not) create a new thread and assign it to the specified message port. Below is a visual description of this process: 1.8. Delivery Logic Transfer Logic The transfer assembly is the core of the server because it moves the data from one basic component to another basic component. This level of data processing logic is as shown below: Once one encapsulation is transmitted to a basic component (received, connected, executed, load), it will be sent to a sub-component, similar to JPOLLD or XDB_LDAP for further processing. An example of a pre-processed may be an XDB (such as a database connection) that needs to be processed. A processing condition can be the sum of all useful routing names in JSM. An example of a transmissive changing may be a change in message format, such as adding an incoming address. TRANSPORTS transmitter Although a robust, XML-based message system structure is the core target of the Jabber project, another important goal is to carry out collaborative works between messaging systems. Fortunately, the Jabber project implements a collaborative job by fully opening its protocol. At the same time, Jabber projects enable communication between Jabber's open XML formats with many non-Jabber formats by using the "Transporter" in the Jabber world. When a Jabber user sends a message to an external (non-jabber) system, the message is transmitted by the transmission of a transmitter component. The user's Jabber client sends a message to the Jabber server and indicates a Jabber ID containing the external system name (such as psaintance@aim.jabber.org) instead of sending a user on the external IM system. The Jabber server then points the data to the specified transmitter application. If the transmitter is local (running on the same machine), the Jabber server communicates directly with it. If the transmitter is not running locally (on another machine), the local server sends a package to the remote server, which will send the package to the specified transmitter. Once the transmitter receives an XML enclosure, it transfers the information (or indication) "transition" into another IM network that can be identified, and transmit this packet into that IM network. Here is an advanced overview of the Jabber Transmitter work: In fact, a transmitter implements a proxy mode. Most transmitters have their own small session manager. This session manager will use online information, message, (sometimes) inquiry information, the conversion between Jabber XML protocols and "outside" (non-Jabber) protocols. In general, when a user logs in to Jabber, the transmitter creates a thread to communicate with this user. Sometimes, the conversion of the Jabber protocol is very direct, for example, when an external protocol is a good documentation (such as the IRC protocol, the AIM protocol "Oscar" version). At some time, it is very difficult to protocol conversion for a natural agreement of closed or documentation (such as Yahoo! Messenger protocol). It is hoped that IM unified organization ((http://www.imunified.org (http://www.imunified.org/))) Some are now able to successfully open or closed message protocol, or at least those closed agreement protocol Conversion creates a set of open protocols. Most transmitters are communicated with non-Jabber services, but there are also individual exceptions. For example, a group chat transmitter, this transmitter allows Jabber users to chat in a chat room or communicate in a similar IRC interface. The group transmitter retains a record of all users currently all users and sends all users of each message to the room, making a room to behave like a mapping server. It creates and destroys the room as needed. If I add a non-existing room, the transmitter will create the room, if I make the last user who leaves the room, the transmitter will destroy this room after I leave. Each single room is identified by a name similar to GroupName @ GroupChatServer, and each participant recognizes a unique description of its nickname. For example, the "groupchat" of the witch in Shakespeare's "Mac White" may happen in a room with cauldron@conference.withces.org, and the witch is identified by the name similar to cauldron@conference.withces.org/firstwitch. The following makes a user may see: 1.10. Subscriptions subscribes to a Jabber entity to subscribe to other Jabber entities (such as any and a Jabber ID) online information, and a subscription is essentially the subscriber agreed to send an online state to the subscriber. This information is stored in the list of subscribers and subscribers. My online information is stored in the Jabber Session Manager when I created a session through the server. When I change my online state, the ? To - another entity to another send online status information ? From "another entity from you get online information ? BOTH - another entity that sends a reproduction information to you, and get an entity that gets online information here. ? None - I don't get the status of reproduction information from you, and don't send online information status to your entity Entities that send online status information are not necessarily another Jabber user, which can also be an external service, such as a data stream or a non-Jabber IM system. In the following example, a user subscription of a non-Jabber system is resolved by a transmitter, and the Jabber user registers to the specified transmitter (such as: icq.jabber.org) to deliver online status information to a non-Jabber system. Once the Jabber user is successfully registered, the transmitter needs to know when the user is online, so it sends an online status information subscription request to the user. A special online status information with "from" features subscription packets generate and transmit from the transmitter, where the data must be available to the local protocol. The Jabber server contains a list of all users' subscription information (which is usually stored in the file system, although this information can be stored in the database). This list is named the roster, very like "friends list" in other IM systems. Jabber's flower name book is placed on the server so that users can freely call from one place to another, from one computer to another. The JABBER server allows, refuses to operate according to the corresponding subscription relationship on the flower roster according to the user's will. The flower name also includes some other users of other information, such as the user's nickname, and the group to which the user belongs. This information can be displayed when the appropriate interface is displayed through the client. 1.11. Jabber IDS Jabber code In Jabber, there are many different entities that need to communicate with each other. These entities can be manifested as a transmitter, a group chat room, or a single Jabber user. Jabber IDs is an internal and external representation of user identity or routing information. The key features of Jabber IDs include: • Use independent objects or entities that determine instant messages and online information status communication • The user can easily remember them and express in the real world They are flexible so that you can include other IM and online information status tables. Each Jabber ID (or JID) includes an ordered element. JIDs consists of domains, nodes, and data stream formats: [node @] domain [/ resource] The Jabber ID element has the following definition: The domain name is the first identifier. It indicates the Jabber server connected to the entity. Each available Jabber domain name should have a complete domain name. The node is the second identifier. It indicates that "user" itself. All nodes correspond to a precise domain. However, the node is optional, a precise domain (such as conference.jabber.org) is an illegal jabber ID. • The resource is an optional third identifier. All resources belong to a node. In JabBer, resources are used to identify special objects belonging to users, such as devices or locations. Resources is a separate user to have several connections to the same Jabber server; such as juliet@capulet.com/balcony vs. juliet@capulet.com/chamber. A Jabber user is usually connected to the server via a special resource, so there is an address in the form of Node @ Domain / Resource (such as juliet@capulet.com/balcony). Due to resource session, the user's address can communicate with Node @ Domain (such as juliet@capulet.com), as in people use Email in the same form of it. Note that although in some cases, the message can be sent directly to a precise resource, but in general, a routing to juliet@capulet.com messages according to the rules on the Jabber server, because each connection instance has its own Priority setting. This way, if a message is sent to juliet@capulet.com (ie, no resource specified), the message routes the resources with the highest priority, such as juliet@capulet.com/balcony. 1.12. Server Dialback server rollback The 1.2 version of the server adds a function that becomes a rollback. This feature is designed to be deceived, so add an additional safety method for the interaction between servers - servers. Details about this feature will be available in the future versions of this document. The following URL provides some preliminary documents: http://docs.jabber.org/draft-proto/html/dialback.html. 1.13. Conclusion Conclusion This document provides a high-order overview of a Jabber system structure. If you have any questions about this document, please contact the author of Email or Jabber and documentation through StPETER@jabber.org (Peter-Saint-Andre). 1.14. CopyRight Information This Document is Copyright 2001 by Peter Saint-Andre. Permission is granted to copy, distribute and / or modify this document under the terms Of the gnu free documentation license (http://www.gnu.org/copyleft/fdl.html), Version 1.1 or Any Later Version Published by The Free Software Foundation, with no Invariant Sections, No Front-Cover Texts, And no Back-cover Texts. You. Obtain A Copy of the gnu free documentation license from the free software findation by Visiting http://www.fsf.org/ or by Writing to: The Free Software Foundation, Inc. 59 TEMPLE PLACE - Suite 330 Boston , MA 02111-1307
