openfire源码分析

启动流程

Socket接口

Socket通信使用Mina框架实现，是XMPP协议的处理入口，具体为：

消息接收后由不同的节处理器处理：

StanzaHandler基础消息类型，之后进行消息路由：

最后通过路由表进行路由：

Http接口

Http接口用于Web端的管理以及Web客户端的通信，使用jetty实现。

通过XMPServer启动ConectionManager来管理链接启动，包括SSL，HTTP，TCP等。

消息处理流程

消息发送

消息的发送通过NIOConnection.deliver(Packet packet)实现。

模块功能列表

启动模块

RoutingTableImpl

/**

* Routing table that stores routes to client sessions, outgoing server sessions

* and components. As soon as a user authenticates with the server its client session

* will be added to the routing table. Whenever the client session becomes available

* or unavailable the routing table will be updated too.<p>

*

* When running inside of a cluster the routing table will also keep references to routes

* hosted in other cluster nodes. A {@link RemotePacketRouter} will be use to route packets

* to routes hosted in other cluster nodes.<p>

*

* Failure to route a packet will end up sending {@link IQRouter#routingFailed(JID, Packet)},

* {@link MessageRouter#routingFailed(JID, Packet)} or {@link PresenceRouter#routingFailed(JID, Packet)}

* depending on the packet type that tried to be sent.

*

* @author Gaston Dombiak

*/

AuditManager

/**

* Manages and directs server message auditing behavior. Turning on

* all auditing options can produce copious amounts of data and

* significantly slow the server as it saves the data to persistent storage.<p>

*

* Auditing currently saves audit data to a raw XML file

* which can later be processed and mined for information.

*

* @author Iain Shigeoka

*/

RostManager

/**

* A simple service that allows components to retrieve a roster based solely on the ID

* of the owner. Users have convenience methods for obtaining a roster associated with

* the owner. However there are many components that need to retrieve the roster

* based solely on the generic ID owner key. This interface defines a service that can

* do that. This allows classes that generically manage resource for resource owners

* (such as presence updates) to generically offer their services without knowing or

* caring if the roster owner is a user, chatbot, etc.

*

* @author Iain Shigeoka

*/

PluginManager

/**

* Loads and manages plugins. The <tt>plugins</tt> directory is monitored for any

* new plugins, and they are dynamically loaded.

*

* <p>An instance of this class can be obtained using:</p>

*

* <tt>XMPPServer.getInstance().getPluginManager()</tt>

*

* @author Matt Tucker

* @see Plugin

* @see org.jivesoftware.openfire.XMPPServer#getPluginManager()

*/

核心模块

PresenceManagerImpl

/**

* The presence manager tracks on a global basis who's online. The presence

* monitor watches and reports on what users are present on the server, and

* in other jabber domains that it knows about. The presence manager does

* not know about invisible users (they are invisible).

*

* @author Iain Shigeoka

*/

SessionManager

/**

* Manages the sessions associated with an account. The information

* maintained by the Session manager is entirely transient and does

* not need to be preserved between server restarts.

*

* @author Derek DeMoro

*/

PacketRouterImpl

/**

* A router that handles incoming packets. Packets will be routed to their

* corresponding handler. A router is much like a forwarded with some logic

* to figute out who is the target for each packet.

*

* @author Gaston Dombiak

*/

IQRouter

/**

* Routes iq packets throughout the server. Routing is based on the recipient

* and sender addresses. The typical packet will often be routed twice, once

* from the sender to some internal server component for handling or processing,

* and then back to the router to be delivered to it's final destination.

*

* @author Iain Shigeoka

*/

MessageRouter

/**

* <p>Route message packets throughout the server.</p>

* <p>Routing is based on the recipient and sender addresses. The typical

* packet will often be routed twice, once from the sender to some internal

* server component for handling or processing, and then back to the router

* to be delivered to it's final destination.</p>

*

* @author Iain Shigeoka

*/

PresenceRouter

/**

* <p>Route presence packets throughout the server.</p>

* <p>Routing is based on the recipient and sender addresses. The typical

* packet will often be routed twice, once from the sender to some internal

* server component for handling or processing, and then back to the router

* to be delivered to it's final destination.</p>

*

* @author Iain Shigeoka

*/

MulticastRouter

将一个包路由到多个目的地址，包括远程地址，但只获取深度为1的地址。

/**

* Router of packets with multiple recipients. Clients may send a single packet with multiple

* recipients and the server will broadcast the packet to the target receipients. If recipients

* belong to remote servers, then this server will discover if remote target servers support

* multicast service. If a remote server supports the multicast service, a single packet will be

* sent to the remote server. If a remote server doesn't the support multicast

* processing, the local server sends a copy of the original stanza to each address.<p>

*

* The current implementation will only search up to the first level of nodes of remote servers

* when trying to find out if remote servers have support for multicast service. It is assumed

* that it is highly unlikely for servers to have a node in the second or third depth level

* providing the multicast service. Servers should normally provide this service themselves or

* at least as a first level node.

*

* This is an implementation of <a href=http://www.jabber.org/jeps/jep-0033.html>

* JEP-0033: Extended Stanza Addressing</a>

*

* @author Matt Tucker

*/

PacketTransporterImpl

/**

* In-memory implementation of the packet transporter service.

*

* @author Iain Shigeoka

*/

PacketDelivererImpl

/**

* In-memory implementation of the packet deliverer service

*

* @author Iain Shigeoka

*/

TransportHandler

/**

* Routes packets to the appropriate transport gateway or drops the packet.

*

* @author Iain Shigeoka

*/

OfflineMessageStrategy

/**

* Controls what is done with offline messages.

*

* @author Iain Shigeoka

*/

OfflineMessageStore

/**

* Represents the user's offline message storage. A message store holds messages that were

* sent to the user while they were unavailable. The user can retrieve their messages by

* setting their presence to "available". The messages will then be delivered normally.

* Offline message storage is optional, in which case a null implementation is returned that

* always throws UnauthorizedException when adding messages to the store.

*

* @author Iain Shigeoka

*/

VCardManager

电子名片管理器

/**

* Manages VCard information for users.

*

* @author Matt Tucker

*/

标准模块

IQBindHandler

/**

* Binds a resource to the stream so that the client's address becomes a full JID. Once a resource

* has been binded to the session the entity (i.e. client) is considered a "connected resource".

* <p>

* Clients may specify a desired resource but if none was specified then the server will create

* a random resource for the session. The new resource should be in accordance with ResourcePrep.

* The server will also verify if there are previous sessions from the same user that are already

* using the resource specified by the user. Depending on the server configuration the old session

* may be kicked or the new session may be rejected.</p>

*

* @author Gaston Dombiak

*/

IQSessionEstablishmentHandler

/**

* Activate client sessions once resource binding has been done. Clients need to active their

* sessions in order to engage in instant messaging and presence activities. The server may

* deny sessions activations if the max number of sessions in the server has been reached or

* if a user does not have permissions to create sessions.<p>

*

* Current implementation does not check any of the above conditions. However, future versions

* may add support for those checkings.

*

* @author Gaston Dombiak

*/

IQAuthHandler

/**

* Implements the TYPE_IQ jabber:iq:auth protocol (plain only). Clients

* use this protocol to authenticate with the server. A 'get' query

* runs an authentication probe with a given user name. Return the

* authentication form or an error indicating the user is not

* registered on the server.<p>

*

* A 'set' query authenticates with information given in the

* authentication form. An authenticated session may reset their

* authentication information using a 'set' query.

*

* <h2>Assumptions</h2>

* This handler assumes that the request is addressed to the server.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

*

* @author Iain Shigeoka

*/

IQPingHandler

/**

* Implements the XMPP Ping as defined by XEP-0199. This protocol offers an

* alternative to the traditional 'white space ping' approach of determining the

* availability of an entity. The XMPP Ping protocol allows pings to be

* performed in a more XML-friendly approach, which can be used over more than

* one hop in the communication path.

*

* @author Guus der Kinderen

* @see <a href="http://www.xmpp.org/extensions/xep-0199.html">XEP-0199:XMPP Ping</a>

*/

IQPrivateHandler

/**

* Implements the TYPE_IQ jabber:iq:private protocol. Clients

* use this protocol to store and retrieve arbitrary application

* configuration information. Using the server for setting storage

* allows client configurations to follow users where ever they go.

* <p>

* A 'get' query retrieves any stored data.

* A 'set' query stores new data.

* </p>

* <p>

* Currently an empty implementation to allow usage with normal

* clients. Future implementation needed.

* </p>

* <h2>Assumptions</h2>

* This handler assumes that the request is addressed to the server.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

* <h2>Warning</h2>

* There should be a way of determining whether a session has

* authorization to access this feature. I'm not sure it is a good

* idea to do authorization in each handler. It would be nice if

* the framework could assert authorization policies across channels.

*

* @author Iain Shigeoka

*/

IQRegisterHandler

完成新用户注册功能。

/**

* Implements the TYPE_IQ jabber:iq:register protocol (plain only). Clients

* use this protocol to register a user account with the server.

* A 'get' query runs a register probe to obtain the fields needed

* for registration. Return the registration form.

* A 'set' query attempts to create a new user account

* with information given in the registration form.

* <h2>Assumptions</h2>

* This handler assumes that the request is addressed to the server.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

* <h2>Compatibility</h2>

* The current behavior is designed to emulate jabberd1.4. However

* this behavior differs significantly from JEP-0078 (non-SASL registration).

* In particular, authentication (IQ-Auth) must return an error when a user

* request is made to an account that doesn't exist to trigger auto-registration

* (JEP-0078 explicitly recommends against this practice to prevent hackers

* from probing for legitimate accounts).

*

* @author Iain Shigeoka

*/

IQRosterHandler

/**

* Implements the TYPE_IQ jabber:iq:roster protocol. Clients

* use this protocol to retrieve, update, and rosterMonitor roster

* entries (buddy lists). The server manages the basics of

* roster subscriptions and roster updates based on presence

* and iq:roster packets, while the client maintains the user

* interface aspects of rosters such as organizing roster

* entries into groups.

* <p>

* A 'get' query retrieves a snapshot of the roster.

* A 'set' query updates the roster (typically with new group info).

* The server sends 'set' updates asynchronously when roster

* entries change status.

* </p>

* <p>

* Currently an empty implementation to allow usage with normal

* clients. Future implementation needed.</p>

* <h2>Assumptions</h2>

* This handler assumes that the request is addressed to the server.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

* <h2>Warning</h2>

* There should be a way of determining whether a session has

* authorization to access this feature. I'm not sure it is a good

* idea to do authorization in each handler. It would be nice if

* the framework could assert authorization policies across channels.

*

* @author Iain Shigeoka

*/

IQTimeHandler

/**

* Implements the TYPE_IQ jabber:iq:time protocol (time info) as

* as defined by JEP-0090. Allows Jabber entities to query each

* other's local time.  The server will respond with its local time.

* <h2>Assumptions</h2>

* This handler assumes that the time request is addressed to itself.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ time requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

* <h2>Warning</h2>

* There should be a way of determining whether a session has

* authorization to access this feature. I'm not sure it is a good

* idea to do authorization in each handler. It would be nice if

* the framework could assert authorization policies across channels.

*

* @author Iain Shigeoka

*/

IQEntityTimeHandler

/**

* This IQ handler implements XEP-0202: Entity Time.

*/

IQvCardHandler

/**

* Implements the TYPE_IQ vcard-temp protocol. Clients

* use this protocol to set and retrieve the vCard information

* associated with someone's account.

* <p>

* A 'get' query retrieves the vcard for the addressee.

* A 'set' query sets the vcard information for the sender's account.

* </p>

* <p>

* Currently an empty implementation to allow usage with normal

* clients. Future implementation needed.

* </p>

* <h2>Assumptions</h2>

* This handler assumes that the request is addressed to the server.

* An appropriate TYPE_IQ tag matcher should be placed in front of this

* one to route TYPE_IQ requests not addressed to the server to

* another channel (probably for direct delivery to the recipient).

* <h2>Warning</h2>

* There should be a way of determining whether a session has

* authorization to access this feature. I'm not sure it is a good

* idea to do authorization in each handler. It would be nice if

* the framework could assert authorization policies across channels.

* <h2>Warning</h2>

* I have noticed incompatibility between vCard XML used by Exodus and Psi.

* There is a new vCard standard going through the JSF JEP process. We might

* want to start either standardizing on clients (probably the most practical),

* sending notices for non-conformance (useful),

* or attempting to translate between client versions (not likely).

*

* @author Iain Shigeoka

*/

IQVersionHandler

/**

* Implements the TYPE_IQ jabber:iq:version protocol (version info). Allows

* XMPP entities to query each other's application versions.  The server

* will respond with its current version info.

*

* @author Iain Shigeoka

*/

IQLastActivityHandler

/**

* Implements the TYPE_IQ jabber:iq:last protocol (last activity). Allows users to find out

* the number of seconds another user has been offline. This information is only available to

* those users that already subscribed to the users presence. Otherwhise, a <tt>forbidden</tt>

* error will be returned.

*

* @author Gaston Dombiak

*/

PresenceSubscribeHandler

/**

* Implements the presence protocol. Clients use this protocol to

* update presence and roster information.

* <p>

* The handler must properly detect the presence type, update the user's roster,

* and inform presence subscribers of the session's updated presence

* status. Presence serves many purposes in Jabber so this handler will

* likely be the most complex of all handlers in the server.</p>

* <p>

* There are four basic types of presence updates:</p>

* <ul>

* <li>Simple presence updates - addressed to the server (or to address), these updates

* are properly addressed by the server, and multicast to

* interested subscribers on the user's roster. An empty, missing,

* or "unavailable" type attribute indicates a simple update (there

* is no "available" type although it should be accepted by the server.

* <li>Directed presence updates - addressed to particular jabber entities,

* these presence updates are properly addressed and directly delivered

* to the entity without broadcast to roster subscribers. Any update type

* is possible except those reserved for subscription requests.

* <li>Subscription requests - these updates request presence subscription

* status changes. Such requests always affect the roster.  The server must:

* <ul>

* <li>update the roster with the proper subscriber info

* <li>push the roster changes to the user

* <li>forward the update to the correct parties.

* </ul>

* The valid types include "subscribe", "subscribed", "unsubscribed",

* and "unsubscribe".

* <li>XMPPServer probes - Provides a mechanism for servers to query the presence

* status of users on another server. This allows users to immediately

* know the presence status of users when they come online rather than way

* for a presence update broadcast from the other server or tracking them

* as they are received.  Requires S2S capabilities.

* </ul>

* <h2>Warning</h2>

* There should be a way of determining whether a session has

* authorization to access this feature. I'm not sure it is a good

* idea to do authorization in each handler. It would be nice if

* the framework could assert authorization policies across channels.

*

* @author Iain Shigeoka

*/

PresenceUpdateHandler

/**

* Implements the presence protocol. Clients use this protocol to

* update presence and roster information.

* <p>

* The handler must properly detect the presence type, update the user's roster,

* and inform presence subscribers of the session's updated presence

* status. Presence serves many purposes in Jabber so this handler will

* likely be the most complex of all handlers in the server.

* </p>

* <p>

* There are four basic types of presence updates:

* </p>

* <ul>

* <li>Simple presence updates - addressed to the server (or to address), these updates

* are properly addressed by the server, and multicast to

* interested subscribers on the user's roster. An empty, missing,

* or "unavailable" type attribute indicates a simple update (there

* is no "available" type although it should be accepted by the server.

* <li>Directed presence updates - addressed to particular jabber entities,

* these presence updates are properly addressed and directly delivered

* to the entity without broadcast to roster subscribers. Any update type

* is possible except those reserved for subscription requests.

* <li>Subscription requests - these updates request presence subscription

* status changes. Such requests always affect the roster.  The server must:

* <ul>

* <li>update the roster with the proper subscriber info

* <li>push the roster changes to the user

* <li>forward the update to the correct parties.

* </ul>

* The valid types include "subscribe", "subscribed", "unsubscribed",

* and "unsubscribe".

* <li>XMPPServer probes - Provides a mechanism for servers to query the presence

* status of users on another server. This allows users to immediately

* know the presence status of users when they come online rather than way

* for a presence update broadcast from the other server or tracking them

* as they are received.  Requires S2S capabilities.

* </ul>

*

* @author Iain Shigeoka

*/

IQOfflineMessagesHandler

/**

* Implements JEP-0013: Flexible Offline Message Retrieval. Allows users to request number of

* messages, request message headers, retrieve specific messages, remove specific messages,

* retrieve all messages and remove all messages.

*

* @author Gaston Dombiak

*/

IQPEPHandler

/**

* <p>

* An {@link IQHandler} used to implement XEP-0163: "Personal Eventing via Pubsub"

* Version 1.0

* </p>

*

* <p>

* For each user on the server there is an associated {@link PEPService} interacting

* with a single {@link PubSubEngine} for managing the user's PEP nodes.

* </p>

*

* <p>

* An IQHandler can only handle one namespace in its IQHandlerInfo. However, PEP

* related packets are seen having a variety of different namespaces. Thus,

* classes like {@link IQPEPOwnerHandler} are used to forward packets having these other

* namespaces to {@link IQPEPHandler#handleIQ(IQ)}.

* <p>

*

* <p>

* This handler is used for the following namespaces:</p>

* <ul>

* <li><i>http://jabber.org/protocol/pubsub</i></li>

* <li><i>http://jabber.org/protocol/pubsub#owner</i></li>

* </ul>

*

* @author Armando Jagucki

* @author Guus der Kinderen, guus.der.kinderen@gmail.com

*/

IQPEPOwnHandler

/**

* <p>

* An {@link IQHandler} used to implement XEP-0163: "Personal Eventing via Pubsub"

* Version 1.0

* </p>

*

* <p>

* An IQHandler can only handle one namespace in its IQHandlerInfo. However, PEP

* related packets are seen having a variety of different namespaces. This

* handler is needed to forward IQ packets with the

* <i>'http://jabber.org/protocol/pubsub#owner'</i> namespace to IQPEPHandler.

* </p>

*

* @author Armando Jagucki

*

*/

MulticastDNSService

/**

* Publishes Openfire information as a service using the Multicast DNS (marketed by Apple

* as Rendezvous) protocol. This lets other nodes on the local network to discover

* the name and port of Openfire.<p>

*

* The multicast DNS entries published:<ul>

*  <li>Client connections: type of "_xmpp-client._tcp.local.".

*  <li>Component connections: type of "_xmpp-component._tcp.local.".

* </ul>

*

* @author Matt Tucker

*/

IQShareGroupHandler

/**

* Handler of IQ packets whose child element is "sharedgroup" with namespace

* "http://www.jivesoftware.org/protocol/sharedgroup". This handler will return the list of

* shared groups where the user sending the request belongs.

*

* @author Gaston Dombiak

*/

AdHocCommandHandler

/**

* An AdHocCommandHandler is responsbile for providing discoverable information about the

* supported commands and for handling commands requests. This is an implementation of JEP-50:

* Ad-Hoc Commands.<p>

*

* Ad-hoc commands that require user interaction will have one or more stages. For each stage the

* user will complete a data form and send it back to the server. The data entered by the user is

* kept in a SessionData. Instances of {@link AdHocCommand} are stateless. In order to prevent

* "bad" users from consuming all system memory there exists a limit of simultaneous commands that

* a user might perform. Configure the system property <tt>"xmpp.command.limit"</tt> to control

* this limit. User sessions will also timeout and their data destroyed if they have not been

* executed within a time limit since the session was created. The default timeout value is 10

* minutes. The timeout value can be modified by setting the system property

* <tt>"xmpp.command.timeout"</tt>.<p>

*

* New commands can be added dynamically by sending the message {@link #addCommand(AdHocCommand)}.

* The command will immediatelly appear in the disco#items list and might be executed by those

* users with enough execution permissions.

*

* @author Gaston Dombiak

*/

IQPrivacyHandler

/**

* IQPrivacyHandler is responsible for handling privacy lists.

*

* @author Gaston Dombiak

*/

DefaultFileTransferManager

/**

* Provides several utility methods for file transfer manager implementaions to utilize.

*

* @author Alexander Wenckus

*/

FileTransferProxy

/**

* Manages the transfering of files between two remote entities on the jabber network.

* This class acts independtly as a Jabber component from the rest of the server, according to

* the Jabber <a href="http://www.jabber.org/jeps/jep-0065.html">SOCKS5 bytestreams protocol</a>.

*

* @author Alexander Wenckus

*/

MediaProxyService

/**

* A proxy service for UDP traffic such as RTP. It provides Jingle transport candidates

* to be used for media transmission. The media proxy is especially useful for users

* behind NAT devices or firewalls that prevent peer to peer communication..

*

* @author Thiago Camargo

*/

PubSubModule

/**

* Module that implements JEP-60: Publish-Subscribe. By default node collections and

* instant nodes are supported.

*

* @author Matt Tucker

*/

IQDiscoInfoHandler

/**

* IQDiscoInfoHandler is responsible for handling disco#info requests. This class holds a map with

* the main entities and the associated DiscoInfoProvider. We are considering the host of the

* recipient JIDs as main entities. It's the DiscoInfoProvider responsibility to provide information

* about the JID's name together with any possible requested node.

* <p>

* For example, let's have in the entities map the following entries: "localhost" and

* "conference.localhost". Associated with each entry we have different DiscoInfoProviders. Now we

* receive a disco#info request for the following JID: "room@conference.localhost" which is a disco

* request for a MUC room. So IQDiscoInfoHandler will look for the DiscoInfoProvider associated

* with the JID's host which in this case is "conference.localhost". Once we have located the

* provider we will delegate to the provider the responsibility to provide the info specific to

* the JID's name which in this case is "room". Among the information that a room could provide we

* could find its identity and the features it supports (e.g. 'muc_passwordprotected',

* 'muc_unmoderated', etc.). Finally, after we have collected all the information provided by the

* provider we will add it to the reply. On the other hand, if no provider was found or the provider

* has no information for the requested name/node then a not-found error will be returned.</p>

*

* @author Gaston Dombiak

*/

IQDiscoItemsHandler

/**

* IQDiscoItemsHandler is responsible for handling disco#items requests. This class holds a map with

* the main entities and the associated DiscoItemsProvider. We are considering the host of the

* recipient JIDs as main entities. It's the DiscoItemsProvider responsibility to provide the items

* associated with the JID's name together with any possible requested node.

* <p>

* For example, let's have in the entities map the following entries: "localhost" and

* "conference.localhost". Associated with each entry we have different DiscoItemsProvider. Now we

* receive a disco#items request for the following JID: "room@conference.localhost" which is a disco

* request for a MUC room. So IQDiscoItemsHandler will look for the DiscoItemsProvider associated

* with the JID's host which in this case is "conference.localhost". Once we have located the

* provider we will delegate to the provider the responsibility to provide the items specific to

* the JID's name which in this case is "room". Depending on the implementation, the items could be

* the list of existing occupants if that information is publicly available. Finally, after we have

* collected all the items provided by the provider we will add them to the reply. On the other

* hand, if no provider was found or the provider has no information for the requested name/node

* then a not-found error will be returned.</p>

* <p>

* Publishing of client items is still not supported.

* </p>

*

* @author Gaston Dombiak

*/

UpdateManager

/**

* Service that frequently checks for new server or plugins releases. By default the service

* will check every 48 hours for updates. Use the system property <tt>update.frequency</tt>

* to set new values.

* <p>

* New versions of plugins can be downloaded and installed. However, new server releases

* should be manually installed.</p>

*

* @author Gaston Dombiak

*/

FlashCrossDomainHandler

Flash跨域访问相关

InternalComponentManager

/**

* Manages the registration and delegation of Components. The ComponentManager

* is responsible for managing registration and delegation of {@link Component Components},

* as well as offering a facade around basic server functionallity such as sending and

* receiving of packets.<p>

*

* This component manager will be an internal service whose JID will be component.[domain]. So the

* component manager will be able to send packets to other internal or external components and also

* receive packets from other components or even from trusted clients (e.g. ad-hoc commands).

*

* @author Derek DeMoro

*/

MultiUserChatManager

/**

* Provides centralized management of all configured Multi User Chat (MUC) services.

*

* @author Daniel Henninger

*/

ClearSpaceManager

/**

* Centralized administration of Clearspace connections. The {@link #getInstance()} method

* should be used to get an instance. The following properties configure this manager:

* <ul>

* <li>clearspace.uri</li>

* <li>clearspace.sharedSecret</li>

* </ul>

*

* @author Daniel Henninger

*/

IQMessageCarbonsHanders

IQ消息副本处理器

/**

* This handler manages XEP-0280 Message Carbons.

*

* @author Christian Schudt

*/

ConnectionManagerImpl

连接管理器，包括管理S2S连接，client连接，compoment连接，multiplexer连接。