启动流程
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连接。