xmpp协议客户端的实现

xmpp协议客户端的实现内容摘要：

体交换信息 ，接收实体必须发起一个反向的握手 (应答流 )。 ◆ XML 节是实体通过 XML 流传输的结构化信息单元 ， 在 XML 流中以深度为 1 的子标记开头 ， 并以深度为 1 的子标记结束 ， 这些标记为 message/、 presence/和 8 iq/。 XML 节是一个实体通过 XML 流向另一个实体发送的结构化信息中的一个离散的语义单位。 一个 XML 直接存在于根元素 stream/的下一级 (在 XML 流中以深度为 1 的子标记开头 ， 并以深度为 1 的子标记结束 )， 并且如果这样就能够满足 [XML]内容的 production 43， 那么它被认为是均衡的。 任何 XML 节都是从一个 XML 流的下一级的某个打开标签 (如 presence)开始 ， 到相应的关闭标签 (如 /presence)。 一个 XML 节可以包含子元素 (相关的属性 ， 元素 ， 和 XML 字符数据等 ) 以表达完整的信息。 在这里定义的 XML 节仅限于 message/， presence/， 和 iq/ 元素；为 TLS 握手、 SASL 握手、服务器回拨的需要而发送的 XML 元素 ， 不被认为是一个 XML 节。 XML 节也可通过包含其他子元素来传送结构化信息 ， 是实际需要交换的信息所在地。 设想一个客户端和服务器会话的例子。 为了连接一个服 务器 ， 一个客户端必须发送一个打开标签 stream给服务器 ， 初始化一个 XML 流 ， 也可选择在这之前发送一段文本声明 XML 版本和支持的字符集 ； 也可看字符编码。 视本地化策略和提供的服务而定 ， 服务器应该回复一个 XML 流给客户端 ， 同样的 ， 也可选择在这之前发送一段文本声明。 一旦客户端完成了 SASL 握手 ， 客户端可以通过流发送不限量的 XML 节给网络中的任何接收者。 当客户端想关闭这个流 ， 它只需要简单的发送一个关闭标签 /stream给服务器 (或者作为另一个选择 ， 可能由服务器关闭这个流 )。 如果会话中发生错误 ， 任何一方均可 用 ERROR 子元素予以应答。 这些情况包括：数据格式不符合 XML 的形式定义、连接超时、寻址错误、非授权错误等。 然后 ， 客户端和服务器都应该彻底地终止这个连接 (通常是一个 TCP 连接 )。 ◆ 流认证是在 XML 流中有关协商传输层安全协议、简单认证与安全层协议和服务器回拨认证协议完成通信认证、加密等目的的数据交互 ， 是 XMPP 安全机制的重要组成部分。 XMPP 为 XML 流扮演通用 “ 传输层 ” 的角色。 XML 流中包含传输的认证信息和现场消息 ， XMPP 能使数据高效路由至最合适的请求源 ， 并最大限度地简化客户机上的实现 ， 使跨应用实时交流 信息成为可能 [11]。 为了防止会话被篡改和偷听 ， XMPP 协议采用认证和加密的方法作为其安全机制 ， 其中认证采用 SASL[7](Simple Authentication and Security Layer)认证和回拨(Dialback)认证 ， 加密利用 TLS(Transport Layer Security)协议。 另外它还设计了端到端数据加密机制作为可选的数据加密策略 ， 保证数据的可靠传输。 XMPP 的协议栈结构如图 3 所示。 9 客户端在连接服务器时 ， 如果服务器要求 ， 客户端必须完成 TLS 协商连接才 可以继续。 协商过程如下： (1)客户端、服务器都打开 Stream； (2)接着服务器发送 STARTTLS 扩展标签给客户端 (包含所支持的认证机制和任何其他流特性 )； (3)客户端发送 STARTTLS 命令给服务器 ， 并等待进一步指示； (4)服务器回复 proceed/标签通知客户端可以继续进行； (5)客户端和服务器尝试通过已有的 TCP 连接完成 TLS 协商； (6)如果认证成功 ， 客户端初始化一个新的流给服务器 ， 否则服务器关闭 TCP 连接。 当 TLS 协商成功后 ， 服务器回复新的 stream给客户端 ， 其中包含服务器 支持的认证机制列表。 客户端在列表中选择需要的认证机制 ， 通过 auth命令通知服务器 ， 接下来双方就可以进行 SASL 认证了。 其过程如下所示： (1)初始化通信过程 ， 客户端和服务器都打开 Stream； (2)服务器向客户端提供安全机制列表； (3)客户端选择所使用的认证机制； (4)服务器发送一次询问信息 ， 其内容包括服务器的部分认证参数； (5)客户端回应服务器的询问 ， 提交授权标识； (6)服务器通知客户端认证成功或失败。 XMPP 的地址空间 (1)概览 [13] 一个实体可以是任何一个被认为是一 个网络端点的东西 (例如网络上的一个 ID)， 而且它是通过 XMPP 进行通信的。 所有这些实体都有一个具有唯一性的地址 ， 并符合 RCF 图 3 XMPP 协议栈结构 10 2396 [URI]规范要求的格式。 由于历史原因 ， 一个 XMPP 实体的地址被称为 Jabber Identifier 或 JID。 一个合法的 JID 包括一组排列好的元素 ， 包括域名 (domain identifier)，节点名 (node identifier)， 和资源名 (resource identifier)。 JID 的语法定义 ， 使用 [ABNF]中的 Augmented BackusNaur 格式。 (IPv4 地址和 IPv6地址规则在 RCF3920 的 附录 B 中的 [IPv6]中定义；确定节点规则的合法字符顺序由RCF3920 的 附录 A 的 [STRINGPREP]的 Nodeprep 部分来定义；确定资源规则的合法字符顺序由 RCF3920 的 附录 B 的 [STRINGPREP]的 Resourceprep 部分来定义；子域名规则参考 [IDNA] 中关于国际域名标签的描述 )。 所有 JID 都是基于上述的结构。 类似 user@host/resource 这种结构 ， 最常用来标识一个即时消息用户 ， 这个用户所连接的服务器 ， 以及这个用户用于连接的资源 (比如特定类型的客户端软件 )。 不过 ， 节点类型不是客户端也是有可能的 ， 比如一个用来提供多用户聊天服务的特定的聊天室 ， 地址可以是 room@service(这里 “room”是聊天室的名字而“service”是多用户聊天服务的主机名 )， 而加入了这个聊天室的某个特定的用户的地址则是 room@service/nick(这里 “nick”是用户在聊天室的昵称 )。 许多其他的 JID 类型都是可能的 (例如 domain/resource可 能是一个服务器端的脚本或服务 )。 一个 JID 的每个合法部分 (节点名 ， 域名 ， 资源名 )的长度不能超过 1023 字节。 也就是整体长度 (包括 39。 @39。 和 39。 /39。 )不能超过 3071 字节。 (2)域名 域名是一个主要的 ID 并且是 JID 中唯一必需的元素 (一个纯粹的域名也是一个合法的 JID)。 它通常代表网络的网关或者 “ 主 ” 服务器 ， 其他实体通过连接它来实现 XML 转发和数据管理功能。 然而 ， 由一个域名标识引用的实体 ， 并非总是一个服务器 ， 它也可能是一个服务器的子域地址 ， 提供额外的功能 (比如多用户聊天服务 ， 用户目录 ， 或一个 到外部消息系统的网关 )。 每个服务器或者服务的域名 ， 可以是一个 IP 地址 ， 但应该是一个完全合法的域名。 一个域名 ID 必须是 [IANA]里定义的 “ 国际化域名 ” ， 并且按 RCF3920 的 [STRINGPREP]中 [NAMEPREP]profile 进行成功的字符转换。 在比较两个域名 ID 之前 ， 服务器 和 客户jid = [ node @ ] domain [ / resource ] domain = fqdn / addressliteral fqdn = (subdomain 1*(. subdomain)) subdomain = (internationalized domain label) addressliteral = IPv4address / IPv6address 11 端应该首先按照 Nameprep profile(定义在 [IANA]中 )来转换每个域名的字符。 XMPP 的三个顶级元素 XMPP 定义了三种核心的 XML 节： message/、 presence/、 iq/(info/query)， 即三个顶级元素 [14]。 这三个顶级元素 (XMPP 节 )拥有五个共同的属性： (1)to：表示该节的预期接收者的 JID； (2)from：表示发送者的 JID； (3)id：可选属性 ， 用于发送实体跟踪它所收发的节； (4)type：表示该节的目的或上下文的详细信息 ， 依据节的类型是消息、在线性信息、还是请求 /响应信息不同 ， 取值有很大不同； (5)xml:lang：如果一个节包含用于显示给人 (human user)看的 XML 字符数据 ， 这个节应该拥有一个 xml:lang 属性 ， 用于指明所 含 XML 字符数据的默认语言。 与 XML 流类似 ， 在 XML 节传输期间 ， 如果产生语义或应用上的错误 ， 任何一方都可以使用 ERROR 元素通知对方。 ◆ Message message/节是 XMPP 中的数据推送机制 ， 一般是从一个客户端到另外一个客户端 ，跟 Email 系统的消息传递有点相似。 不过 ， 跟 Email 系统不同的是 ， 这种消息传递是非常实时的。 因为 ， 通过在线性探测机制 ， 发送的一方总是能够知道接收方是否在线并是否做好接收的准备。 在发送的时候 ， 所有的 message 节都带有 to 属性 ， 服务器会根据这一属性路由其收到的 message 消息。 XMPP 中定义了五种类型的消息 ， 分别 是： normal、 chat、 groupchat、error、 headline。 另外 ， message/节可以包含以下几个子元素 ， 分别是 ： error、 subject、 body、 thread。 在消息体中一个简单 message 包的示例 如下页代码 ： ◆ Presence message from=‟qhg@ ‟ to=‟/home‟ id=‟messageid1‟ threadthreadid_01/thread subjectThe message‟s subject/subject bodyThe text in the message body/body /message 12 presence/节是 XMPP 中的数据广播机制 ， 由服务器接收并向所有相关目的方进行广播 ， 这种机制又有点类似订阅 /发布类型的消息传 递。 目前主要用于实现 IM 当中的联系人管理功能。 presence 节的 type 属性是可选的 ， 如果省略 ， 则用来通知服务器发送者已经在线并且可以进行通信。 presence 节中可以包含 show/、 status/、 priority/等子元素。 Presence 包的简单示例： ◆ iq/(Info/Query) iq/(info/query)节是 XMPP 中的数据请求与答复 (request/response)机制 ， 比较类似HTTP 的工作机制。 通 过这一语义单元 ， 一个实体可以向另一实体发出请求 ， 以及接收对方的应答。 XMPP 协议针对 IQ 节制定了以下规则： (1)对于 IQ 节来说 ， id 属性是必需的； (2)对于 IQ 节来说 ， type 属性是必需的 ， 它的取值 如下表 1： 表 1 IQ 元素的四种状态 (3)一个接收到 get 或 set 类型的 IQ 请求的实体必须回复一个 result 或 error 类型的IQ 应答 (这个应答必须保留相关请求的 id 属性 )； (4)一个接收到 result 或 error 类型的 IQ 节的实体不能再发送更多的 result 或 error值 描述 get 这个节是一个对信息或需求的请求 set 这个节提供需要的数据 ， 设置新的值或取代现有的值 result 这个节是对一个成功的 get 或 set 请求的应答 error 在处理或传递以前发送的请求时发生了错误 presence from=‟qhg@ ‟ to=‟ ‟ type=‟available‟ statusI‟m bored out of my mind， talk to me/status priority10/priority showchat/show /presence 13 类型的 IQ 应答。 IQ 元素可以用于不同的目的 ， 它们之间通过不同的命名空间来加以区分。 在 XMPP协议中有许多命名空间 ， 比较常用的命名。