gloox 之 MainPage

前言

gloox库是按照“观察者”模式设计的，意思就是说一切都是事件驱动的。

使用gloox有两种方法可以连接到Jabber/XMPP网络，它们是客户端或组件。

第三种是作为服务器，但是gloox不支持，尽管某些方面支持服务器。
注意：XMPP详细规格说明书（RFC 3290）要求，线路上交换的数据只能是UTF-8编码方式。
因为gloox不知道输入的数据是何种编码，所以传给gloox的任何数据都必须是有效的UTF-8编码。

Event Handlers(事件处理器)

gloox最有用的工具就是事件处理器。
当前，不仅有为RFC中定义的基本协议服务的4种事件处理器，而且还有为XEP实现里的事件和附加功能服务的众多事件处理器。
另外，一个登录处理器，一个一般标签处理器和一个连接事件处理器，它们都是有效的。

几乎这些处理器都是虚拟接口，你可以通过它派生出子类和实现其中的虚函数。
然后你用各自的协议实现注册此子类对象。简单例子如下：
 class MyClass : public PresenceHandler {   public:     // reimplemented from PresenceHandler     virtual void handlePresence( Stanza *stanza );   [...] }; void MyClass::handlePresence( Stanza *stanza ) {   // extract further information from the stanza } 

在某些地方你像这样：

OtherClass::doSomething() {      Client *client = new Client( ... );      [...]      MyClass *handler = new MyClass( ... );         //注册此事件处理器（此处是出席处理）      client->registerPresenceHandler( handler ); } 
 
现在，在任何时间收到一个出席节（a presence stanza），MyClass::handlePresence()就会被调用，
当前节（current stanza）作为参数被传入进此函数。
然后你可以使用Stanza类提供的众多getters（即get前缀的成员函数）进一步提取节中的数据。

几乎所有的事件处理器都是这样类似地工作方式。以连接处理器（ConnectionListener类）再举一例：

class MyClass : public ConnectionListener {   public:     virtual void onConnect();     virtual bool onTLSConnect( ... ); }; void MyClass::onConnect() {   // do something when the connection is established（连接建立时的操作） } bool MyClass::onTLSConnect( const CertInfo& info ) {   // decide whether you trust the certificate, examine the CertInfo structure   //（审核CertInfo中的数据，确定是否相信此证书）   return true; // if you trust it, otherwise return false（相信返回 true,否则返回false） } 
注意：ConnectionListener类与众不同。
如果你想成功地连接到一个启用TLS/SSL的服务器，必须重新实现ConnectionListener::onTLSConnect()函数。
尽管gloox试着去检查服务器证书，但不会自动信任此服务器。客户端程序员或用户不得不自己决定是否信任此服务器。
“是否信任”是通过onTLSConnect()函数返回值表示的，让此函数返回false，则表示你不信任此服务器或此证书，
与服务器的连接立刻断开。

components(组件)

Jabber/XMPP网络中的一个组件是加载到服务器上的，它运行在实际的服务软件之外，但它有相似的权限。
组件使用XEP-0114中描述的协议去连接和验证一个服务器。
Component类支持上述协议，利用它可以创建一个新的Jabber组件，就像下面一样简单：

Component *comp = new Component( ... );
comp->connect();

Clients（客户端）

一个客户端可以是最终用户的聊天窗口，一个自动代理，或是一个没有和特殊服务器绑定在一起的简单实体。
Client类实现了连接到一个XMPP服务器必需的功能。一个漂亮的例子如下：
class MyClass : public ConnectionListener, PresenceHandler {   public:     void doSomething();     virtual void handlePresence( ... );     virtual void onConnect();     virtual bool onTLSConnect( const CertInfo& info ); }; void MyClass::doSomething() {   JID jid( "jid@server/resource" );   Client *client = new Client( jid, "password" );   client->registerConnectionListener( this );   client->registerPresenceHandler( this );   client->connect(); } void MyClass::onConnect() {   // connection established, auth done (see API docs for exceptions)（连接建立，如果异常，请查阅文档） } bool MyClass::onTLSConnect( const CertInfo& info ) {   // examine certificate info（检查证书信息） } void MyClass::handlePresence( Stanza *stanza ) {   // presence info（进一步提取节里的数据） } 

注意：gloox不支持（将来也不会支持）基于5223端口上的连接，
也就是说，SSL加密先于任何XML被发送，这是因为历史原因，况且不符合XMPP标准。
默认情况下，Client::connect()是阻塞的，一直到连接终止（调用Client::disconnect()或服务器关闭连接）。

Blocking vs. Non-blocking Connections （ 阻塞连接 与 非阻塞连接 比较 ）

一些类型的自动代理采用阻塞连接（即默认）比较好。所有的自动代理都是处理服务器发来的数据。
尽管如此，对最终客户端或基于图形界面（GUI）的应用来说就远远不足了。
在这种情况下，就要使用非阻塞连接了。如果这样调用ClientBase::connect(false)，此函数在连接成功后会立即返回。
然后程序员就有责任初始化一些从套接字收到的数据。
一种简单的方法是，以一个数字作为超时参数周期地调用ClientBase::recv()。
此参数默认值－1，意思是此调用会一直阻塞，直到收到一些数据，然后它会自动解析这些数据。
作为周期性地轮询一种替换办法，你可以得到连接的原始文件描述符。
然后在其上调用select()函数或当选择那些数据有效时调用ClientBase::recv()。
你可能直接从文件描述符得不到任何数据，也没有办法为解析器提供数据。

为了得到文件描述符，你必须手动设置一个连接类，就像这样：

 Client* client = new Client( ... );
 ConnectionTCPClient* conn = new ConnectionTCPClient( client, client->logInstance(), server, port );
 client->setConnectionImpl( conn );

 client->connect( false );
 int sock = conn->socket();

 [...]
你也可以这样取出：

Client* client = new Client( ... );
 client->connect( false );
 int sock = dynamic_cast<ConnectionTCPClient*>( client->connectionImpl() )->socket();

 [...]

注意：这些在0.9以后的版本中己经改变，ClientBase::fileDescriptor()不再有效。

Roster Management （花名册管理）

其它，RFC3921定义了管理一个人的联系人列表（花名册）的协议。gloox 的RosterManager类实现了此功能。
几个简单实用的函数可以有效地订阅或取消订阅远端实体的出席。
也可以在没有实际订阅此联系人出席的情况，把他加入到自己的花名册中。
另外，RosterListener接口类提供了一些回调函数，用于与花名册有关的各种各样的事件。
如果你像前面演示那样创建了一个Client对象，那么你就己经拥有了一个RosterManager对象，
调用Client::rosterManager()就会返回此对象的指针。

Privacy Lists （隐秘列表）

同样定义于RFC3921中的Privacy Lists。一个隐秘列表可以明确地禁止或允许 从联系人接收或发给联系人数据节，区分不同的联系人。你可以自己定义基于JID,节类型等的规则。不要说gloox实现了非

常好的隐秘列表。PrivacyManager类和PrivacyListHandler虚拟接口类在在处理隐秘列表上机动灵活。

 PrivacyManager *p = new PrivacyManager( ... );
 [...]
 PrivacyListHandler::PrivacyList list;
 PrivacyItem item( PrivacyItem::TypeJid, PrivacyItem::ActionDeny,
                   PrivacyItem::PacketMessage, "[e-mail]" );
 list.push_back( item );

 PrivacyItem item2( PrivacyItem::TypeJid, PrivacyItem::ActionAllow,
                    PrivacyItem::PacketIq, "[e-mail]" );
 list.push_back( item2 );

 p->store( "myList", list );

Authentication （认证）

gloox 支持基于老旧的XEP-0078定义的IQ认证，也支持SASL的机制。更多内容请参考Client类文档。

Sending and Receiving fo Chat Messages ( 聊天消息的收发 )

对于消息传递，建议使用MessageSession虚拟接口类。它处理消息的收发，消息事件和聊天状态。
更多细节请参阅MessageSession文档。

Protocol Enhancements（XEPs）（扩展协议）

XMPP标准基金会发布了许多核心协议的扩展，称为XMPP Extension Protocols(XEPs)(XMPP扩展协议)。
几个扩展协议己经在gloox中得到实现。

    * XEP-0004 Data Forms
    * XEP-0012 Last Activity
    * XEP-0013 Flexible Offline Message Retrieval
    * XEP-0022 Message Events (see MessageSession for examples)
    * XEP-0027 Current Jabber OpenPGP Usage (see GPGSigned and GPGEncrypted )
    * XEP-0030 Service Discovery
    * XEP-0045 Multi-User Chat
    * XEP-0047 In-Band Bytestreams
    * XEP-0048 Bookmark Storage
    * XEP-0049 Private XML Storage
    * XEP-0050 Ad-hoc Commands
    * XEP-0054 vcard-temp
    * XEP-0065 SOCKS5 Bytestreams , used with File Transfer and HTTP and SOCKS5 Proxy support
    * XEP-0066 Out of Band Data
    * XEP-0077 In-Band Registration
    * XEP-0078 Non-SASL Authentication (automatically used if the server does not support SASL)
    * XEP-0083 Nested Roster Groups (automatically used if supported by the server. see RosterManager )
    * XEP-0085 Chat State Notifications (see MessageSession for examples)
    * XEP-0091 Delayed Delivery (old spec)
    * XEP-0092 Software Version (integrated into Service Discovery )
    * XEP-0095 Stream Initiation , used with File Transfer
    * XEP-0096 File Transfer
    * XEP-0114 Jabber Component Protocol
    * XEP-0138 Stream Compression (used automatically if gloox is compiled with zlib and if the server supports it)
    * XEP-0145 Annotations
    * XEP-0153 vCard-based Avatars
    * XEP-0203 Delayed Delivery (new spec)

File Transfer  (文件传输)

为了文件传输，gloox 实现了XEP-0095(流初始化)以及XEP-0096(文件传输)的信号机制，
为传输实现了XEP-0065(SOCKS5 Bytestreams 流字节)。参考 SIProfileFT类。
另外，XEP-0047（In-Band Bytestreams）的实现目前在XEPs 0095 和 0096的信号上还不完整。
所以，gloox也许不适合向远程传送文件。参考InBandBytestreamManager类。

HTTP and SOCKS5 Proxy support (http和socks5代理支持 )

gloox 有能力穿过http及SOCKS5代理，即便是连锁代理。参考ConnectionHTTPProxy类 和 ConnectionSocks5Proxy类