最近想做一个游戏服务器和 IM 互通的服务。最初的想法是可以增进游戏帐号的安全，比如游戏用户可以通过绑定一个 IM 帐号，从而不用登陆游戏就向游戏服务器发一些指令。这些指定通常是用来冻结一些帐号的功能。而游戏服务器也可以通过 IM 帐号向离线用户发送一些关键消息。这样，只需要解除绑定 IM 帐号需要一定的时间，或使用更安全的途径，即可以让游戏帐号更加安全。（至少，游戏用户可以从 IM 上获知他的游戏帐号每次登陆登出的时间、IP 等等）

后来细想，这里面可以做的东西还有许多。玩家会因为多一个信息通道，而更轻松的去玩那些需要长期驻留的游戏。游戏厂商也可以多一个挽留玩家的渠道，甚至用来宣传新游戏或游戏的增值服务，等等。好处不再列举。

其实、绑定 IM 帐号和绑定手机号本质上区别不大。只不过，IM 帐号几乎是零费用，又不像 SMS ，控制权掌控在移动手里。IM 更适合做双向交流（SMS 的双向交流不那么方便，而且对用户和游戏运营商都有经济负担）。独立提供一个 Game2IM 的服务供众多游戏运营商使用也是个有趣的主意。和 SMS 一样，只要给出一个简单接口让游戏运营商调用，把游戏网络和 IM 网络互联就可以了。

实现这个想法有两个方案。其一是制作各种 IM 的机器人，通过机器人和用户 IM 沟通。这个方案技术门槛稍低，有许多现成的机器人可以使用。缺点是，受 IM 提供商的限制（比如好友数量限制）。无法使用机器人的签名针对性的向用户传递特有的消息。除非你为每个游戏用户定制一个机器人，但那样，每个机器人都需要单独一个连接，对资源消耗过大。 

第二个方案就是使用已有的 IM 互通方案，自己提供一个特有的 Game-IM 网络，跟已有的 IM 网络互通。比较流行的 IM 互通协议用基于 SIP 的 SIMPLE 和起源于 Jabber 的 XMPP 。

我最常用的 IM 是 google talk ，本身就实现了标准的 XMPP Client 和 XMPP Server 协议；而我们的 网易 popo 也实现了 XMPP 的 s2s 网关。我想研究一下 XMPP 是个不错的选择。

花了一整天的时间，把 XMPP 核心协议 仔细通读了一遍，收获颇多。原来以为 XMPP 是个可怕的巨无霸。我对 XML 原本也没有太多好感。最后，看法有所改变。

其实，XMPP 仅仅是定义了一个网络服务间相互通讯的协议。它已经把服务间需要关心的东西减少到了最少。具体的应用每家服务提供商可以随意扩展。popo 在制作新版本时，我曾多次建议采用已有的标准协议，再此基础上开发自己的东西。当时或许大家都认为标准协议容易促手促脚，我当时也没啥研究，没有多言。今天看来，我更觉得这是一个决策失误。本来我们有一个很好的机会，利用 popo 联系起网易的各种服务，现在这条路将走的更为艰辛。其实，XMPP 定义的东西，即使自己去设计也会定义出类似的一套来。而把各种网络服务互通本该是发展的重点，为 IM Client 增添专有花哨的特性就有些舍本逐末了。更为恼火的是，popo 到现在也没有一个很好的非 Windows 平台解决方案。怎能让诸多把握着互联网上部分话语权的技术人士接受？（或者，同在杭州的 IT 圈子，popo 的开发人员是不是应该看看支付宝的同行们做了些什么？）

谈谈我对 XMPP 的粗浅理解。这些仅仅建立在我对 RFC3920 的一天阅读的基础上，难免会有错误，不足以做技术参考。

XMPP 抽象出一个在互联网上唯一的对象实体，用 JID 来表达。通常一个 JID 由三部分组成，node@domain/resource 。比 email 的表达形式多了一个 /resource 。这是因为 email 地址本身虽然可以表达一个实体，都是往往不够表达这个实体下的具体服务。就好比一个 ip 地址可以表示一台机器，但是我们还需要 port 号来表达这台机器具体提供的服务一样。

用过 gtalk 的人应该很喜欢 gtalk 可以在不同的地方同时登陆这个不错的特性。用过以后，才能体会，无论是 qq 还是 msn 还是 popo ，只允许一个登陆是多么愚蠢的设定。gtalk 其实遵守了标准的 XMPP 协议，它用来区别一个帐号（一般是一个 gmail 邮件地址）的多处登陆，正是利用了不同的 resource 标识。

XMPP 规范的最重要的一条通信协议就是，如何把消息从一个 JID 发送到另一个 JID (message)。这有点像 email 协议，但不同的是，它强调了实时性和安全性（虽然不是必须的）。因为 JID 可以在不同的 domain 下，这就需要 domain 间相互协作。对于 IM 网络来说（XMPP 远不只用于 IM 协议），就是不同的 IM 服务间互通。

对于 domain 下的 xmpp 服务的发现，利用了 DNS 协议的一些功能。xmpp 的 s2s 服务提供位置，放在了 DNS 的 SRV 记录里。你可以用 nslookup 做个试验，启动 nslookup ，输入 set type=SRV

然后查询 _xmpp-server._tcp.gmail.com 你会发现 gmail.com 的 xmpp s2s 服务地址已经端口号 5269 。同样，也可以查询 _xmpp-server._tcp.163.com 或 _xmpp-server._tcp.popo.163.com 查到网易 popo 的 xmpp 中转服务器地址。

btw, 查询 _xmpp-client._tcp.gmail.com 可以查到 gtalk 的 client 登陆地址，而网易 popo 则没有提供 xmpp client 登陆点。

按 RFC3920 所述，在 xmpp server 互联的时候，会优先尝试获取 domain 的 SRV 记录，如果失败就直接去连默认的 6259 端口。然后就可以开始握手协议。

xmpp 比较强调 s2s 的安全性，所以推荐的握手都是建立在 TLS 层之上，使用 SASL 认证。TLS 层需要服务器有一个数字证书，为了安全可信，建议是找个根证书签名。不过自己签名也行，只需要服务器缓存证书即可。握手过程在 RFC3920 中描述的非常细致，可以按照其编码，问题不大。需要注意的是，这里的 XML 流格式要求很精确，不允许传输多余的东西。我一度认为采用 XML 会导致协议的实现上非常臃肿，其实不然。采用 XML 只是一个表象，适合人阅读和调错而已。RFC 中特别要求不去实现 XML 中的某某特性就是一例。我们不应该为了 XML 而去 XML 。

其实 XMPP 的 c2s 和 s2s 并无太大区别，s2s 做的人手我想是因为开源项目和开源库比较少吧。而开源的 client 实现则是一大堆。c2s 和 s2s 的通讯都是基于那几条协议而已，s2s 的实现难点在于握手比较复杂（其实 c2s 也一样，只是很多库帮你做好了）。c2s 是共享一个 tcp 连接做双向通讯；而 s2s 则是用两条 TCP 连接。两条连接也一定程度上避免了 s2s 的欺骗，当然真正的安全来至于 TLS 和 SASL 的保障。DNS 毕竟是一个很脆弱的东西。

除了点对点消息外，XMPP 定义了消息的组播。也就是一个 JID 可以以自己的名义发布消息 (presence)。而服务器来决定该发给谁。发送目标是由订阅消息决定的。其它多个 JID 可以订阅某个 JID 的消息。对于 IM 来说，最常用的就是上线下线等状态变化消息了。

第三条即是对某个 JID 的状态进行设置和获取 (iq)。于 IM 应用来说，设置签名，昵称，状态等都依赖于它。

XMPP 的核心协议无非规定了以上三种通讯协议，此外规范了服务器间互连的握手认证方案。然后给出了一些错误信息的表述方法。稍微了解过之后，很容易编写。如果希望重造轮子的话，对于 C 语言开发者来说，最繁琐的可能是 XML 的解析于生成。我自己稍微考察了一下，有个叫 LoudMouth 的库还不错。

如果实现 s2s 网关的话，有些细节做起来可能很麻烦，比如查询 DNS 的 SRV 记录。这个在 jabberd 1.x 里其实有独立的模块实现好了，取来用即可 (见 dnsrv) 。而 TLS SASL 层的实现则早就有现成的开源库了。

实现一个 jabber server 或许比你想象的还简单。in.jabberd 居然只用 600 多行 C 代码就从零实现了一个 jabber 服务器。当然功能非常的简陋了。

至于我想做的东西，我希望一个在名为 xyz 的梦幻西游服务器上的 12345 号玩家，一旦选择绑定他的 popo 帐号 player@popo.163.com ，他在他的 popo 上就会收到名叫 12345.xyz@xyq.163.com 的好友请求。当他通过好友认证后，就可以从这个通道获取游戏里的信息，也可以对游戏帐号做有限的操作。我想有了这样一项服务，对玩家对运营商都会有极大的好处的。 其他资源： 使用 XMPP 构建一个基于 web 的通知工具