Jabber学习笔记 之二

三、Jabber核心协议（XMPP Core ：RFC3920）
1、 [b]／XML Stanza[/b]XML Stream
Stream ：以<stream>开始，至</stream>结束，在整个生命周期中，可以包含任意数量的XML元素
Stanza：Stream中结构化的XML片断
整个流看起来大致如下：

 
 
2、 Stream Attributes
to ：用于发起方stream 中（initial stream），表明接收者，响应Stream不能包含to，如果有则被忽略；
from ：用于响应Stream中（response stream），表明接收者，发起方Stream不能包含from，如果有则被忽略；
id ：用于响应Stream中，唯一性标识，出于安全性考虑，建议随机生成；
xml:lang：缺省语言
version：版本号，通常为1.0
 
3、 Stream Error:
当遇到有stream级别的错误时，需要发送一个<error/>tag，具体语法如下：

 
defined-condition举例：<xml-not-well-formed/>、<not-authorized/>、<bad-format/>、<host-unknown/>等
 
4、 Transport Layer Security (TLS) protocol
当一个Stream被发起以后，需要通过TLS来保证连接的安全性，下面是一个从客户端到服务器的例子。
Step 1: Client initiates stream to server:

Step 2: Server responds by sending a stream tag to client:

Step 3: Server sends the STARTTLS extension to client along with authentication mechanisms and any other stream features:

Step 4: Client sends the STARTTLS command to server:

Step 5: Server informs client that it is allowed to proceed:

Step 5 (alt): Server informs client that TLS negotiation has failed and closes both stream and TCP connection:

Step 6: Client and server attempt to complete TLS negotiation over the existing TCP connection.
Step 7: If TLS negotiation is successful, client initiates a new stream to server:

Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP connection.
Step 8: Server responds by sending a stream header to client along with any available stream features:

Step 9: Client continues with SASL negotiation (Use of SASL).
 
5、Simple Authentication and Security Layer (SASL) protocol
在TLS之后是用户的安全认证，采用SASL协议，下面是一个从client到server的例子：
   Step 1: Client initiates stream to server:

Step 2: Server responds with a stream tag sent to client:

Step 3: Server informs client of available authentication mechanisms:

Step 4: Client selects an authentication mechanism:

Step 5: Server sends a [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded challenge to client:

The decoded challenge is:

Step 5 (alt): Server returns error to client:

Step 6: Client sends a [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded response to the challenge:

The decoded response is:

Step 7: Server sends another [BASE64] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) encoded challenge to client:

The decoded challenge is:

Step 7 (alt): Server returns error to client:

Step 8: Client responds to the challenge:

Step 9: Server informs client of successful authentication:

Step 9 (alt): Server informs client of failed authentication:

Step 10: Client initiates a new stream to server:

Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):

 
6、  Resource Binding
SASL之后便是Resource Binding，但这个只是client到server时需要，而server与server之间不需要。
    Server advertises resource binding feature to client:

If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element:
Client asks server to bind a resource:

A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.
If the client wishes to specify the resource identifier, it sends an IQ stanza of type "set" that contains the desired resource identifier as the XML character data of a <resource/> element that is a child of the <bind/> element:
Client binds a resource:

Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:
Server informs client of successful resource binding:

A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above.
When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors (Stanza Errors)):
[align=left]·         The provided resource identifier cannot be processed by the server in accordance with Resourceprep (Resourceprep). [/align]
[align=left]·         The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed). [/align]
[align=left]·         The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier. [/align]
The protocol for these error conditions is shown below.
Resource identifier cannot be processed:

Client is not allowed to bind a resource:

Resource identifier is in use:

If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.
 
7、  XML Stanzas
'jabber:client'和'jabber:server'命名空间定义了三种stanza:<message/>、 <presence/>、<iq/>.
       详细定义需要学习RFC3921。
8、  实验
分别选择两个Jab
bc6c
ber Server做连接测试：
第一个：jabber.org
telnet jabber.org 5222
<?xml version='1.0'?>
<stream:stream
       to='jabber.org'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
收到如下内容：
<?xml version='1.0'?>
<stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       id='94769953'
       from='jabber.org'
       version='1.0'
       xml:lang='en'>
      
       <stream:features>
              <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
              <compression xmlns='http://jabber.org/features/compress'>
                     <method>zlib</method>
              </compression>                  
              <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
                     <mechanism>DIGEST-MD5</mechanism>
                     <mechanism>PLAIN</mechanism>
              </mechanisms>
              <register xmlns='http://jabber.org/features/iq-register'/>
       </stream:features>
从返回的内容来看，基本上跟RFC3720所说一致，不过多了一个压缩？，接下来就没法进行了，看来还得研究一下压缩算法
 
第二个：talk.google.com，这个就是大名鼎鼎的Google Talk了，由于也是采用XMPP，因此也可能连接：
telnet talk.google.com 5222
<?xml version='1.0'?>
<stream:stream
       to='google.com'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
收到内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<stream:stream from="google.com"
       id="8F2DEA3E08EDD09C"
       version="1.0"
       xmlns:stream="http://etherx.jabber.org/streams"
       xmlns="jabber:client">
       <stream:features>
              <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
              <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
                     <mechanism>X-GOOGLE-TOKEN</mechanism>
              </mechanisms>
       </stream:features>
google talk倒是没采用压缩算法，不过居然是自己专用的SASL。
接下来发送：
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
收到：
<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
TLS还是能够顺利进行的，接下来的就没法进行了。可以看出跟Google Talk通信是可行的，只不过需要熟悉Google Talk的扩展协议，目前暂时还没有收集这方面的资料。