gloox 之 MainPage

本文章转载与http://hi.baidu.com/ln5336993/blog/item/54fa8d283e31d3ea98250adb.html

gloox mainPage：http://camaya.net/api/gloox-1.0/index.html

前言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, "me@there.com" );  list.push_back( item ); PrivacyItem item2( PrivacyItem::TypeJid, PrivacyItem::ActionAllow,                     PrivacyItem::PacketIq, "me@example.org" );  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类