关于下一代IM服务器的一点想法
1、引言
当前IM的站场上依旧硝烟弥漫，QQ, MSN, Google Talk, ICQ, Yahoo!还都在争夺着市场的份额。今天我所要说的，是跳出商业利益趋势之短利，而从长远的角度考虑IM的发展趋势。
目前各大IM各自为政，在互相学习中提供着越来越丰富的功能。在他们疯狂的瓜分着internet用户市场的时候，我们普通的用户成了他们商业竞争的受害 人。恕不见，因为自己的朋友有着不同的IM，为了与他们通讯，我们只好自己申请成为那个IM的用户。结果，每个人一开机，就有着少则3－4个IM同时叮叮 咚咚的启动，多则6－7个。
虽然也有着多合一的IM客户端，但是一来有些功能由于这种整合客户端所限，我们无法使用；二来，我们依旧需要管理着越来越多的帐户和密码。不少人因为犯懒，而多个帐户使用一个密码，结果导致一个密码被人知道后，其他的密码也被人家猜到了，而使信息泄密。
如何让用户面对一个简单的界面，用最少的用户名密码对完成所必须的IM通讯呢？
现今的世界，唯有开放，方能生存。
我的想法是各个IM服务器之间互连，不要再那么封闭了。IM服务器遵循某种标准的IM通讯协议，然后就像email服务器那样，虽然IM服务器不同，IM的服务不同，但是他们之间可以共享最基本的消息通讯。
这样QQ的用户可以添加MSN的好友，并且可以与MSN的好友交流，而不必非注册一个MSN帐户。各个IM服务提供商，由IM孤岛，变成了IM接入点，所 有的IM孤岛互联，组成一个IM的服务器网络，或者世界。成为任何一个IM的用户，都可以与这个IM世界里的任何服务器的任何用户交流，而无须非在对方的 IM服务器上注册用户。
其实这种思想在Email身上有很好的体现。虽然大家的email服务器不同，注册的服务不同。但是我们依旧可以和不同的email服务器上用户通讯，而不必非得在对方的email服务器上注册一个用户。
如果从email的视角看今天的IM的话，那么称今天的IM为IM孤岛(IM Island)，一点都不为过。未来是互联而开放的世界，任何孤岛都会被打破，互联是一种必然的趋势。
其实抽象一下IM，虽然IM的功能五花八门，但是我们90%以上的时间就是在使用下面这几个公共的特性：
以这个通用的协议为基础，所有加入IM World的IM服务器，必须遵守这个通用IM协议，并采用这个协议互相通讯。就可以完成IM世界里面基本交流无障碍。当然，IM服务商，会除这个通用协 议中要求的这些特性外，提供更多额外的服务给用户，以吸引用户使用自己的IM作为IM World的接入点。
互联导致IM用户群的整合，对于任何的IM服务商，都是用户群的扩大，由于共同制定和完善通用IM标准，也会使标准更加完善，通讯更稳定。
这是考验一个公司和决策人气魄和胆识的时候。不同的公司和决策人会作出不同的反应。
到底是给自己的用户加上沉重的枷锁，关起门来不让他们跑掉？还是摆出自信和开放的姿态，敞开大门，欢迎其他的IM与自己的消息互通？
并不是所有的人都能够真正的把目光放长远，能够作出开放的姿态的。但是，趋势是一定的，已经有一些小范围的消息互通，但是还不足够。让我们拭目以待，看看谁是这个敢吃螃蟹的人，让这个世界的IM成功的互联起来。
我下面就说两种互通的例子，第一个是一个开放的IM服务器和一个封闭的IM服务器，目前以QQ为例，通过QQ Bridge，或者叫做QQ网关，进行互通的例子。第二个，是让IM服务器分布式，类似于email和dns那样，im服务器同联盟服务器通讯，使得不同 的IM用户可以互相通讯。
2、可以添加QQ好友，并且可以与QQ好友通讯的IM服务器
2.1 背景
在这个图中，800001 - 800002是QQ用户，他们使用自己的计算机，分别连接QQ不同的服务器。而Universal IM服务器则是另一个IM服务商，我们虚构一个名字叫做Universal IM，简称(UIM)。属于这个IM服务商的有[email protected]， [email protected], [email protected]这3个用户。
QQ Bridge 服务器，实际上是一个虚拟的多个QQ客户端的服务器，当前他有两个QQ帐户，一个是900001，另一个是900002。
当我们忽略掉QQ Bridge服务器的时候，这就是典型的两个IM服务商，他们拥有自己的用户群，而这些用户群中的用户不可以跨群访问。也就是说800001永远无法和 [email protected]取得联系，无论是加好友还是发消息都不行。
这就是我们目前大部分IM的现状。
我的想法是，在UIM服务器和QQ服务器中间建立起一个桥梁。由于QQ的思想并不开放，所以，我们将这个QQ Bridge服务器放在靠近UIM的位置，并且将其视为UIM服务器的一个子模块。当然，如果QQ是开放的，那么这个QQ Bridge就要改名为QQ-UIM Gateway了，并且独立出来，做QQ服务器和UIM服务器的消息路由。
暂且，我们先将其视为UIM的一个模块（毕竟这符合QQ当前的封闭策略）。
首先，UIM管理人员，申请若干个合法的QQ帐户，在此例子中，是900001, 900002。
2.2 通讯过程
背景清楚后，通讯过程就比较好理解了。假设zhangxiaofan（张小凡）这个用户有一个好友小白，那个好友的QQ号是800003。如果没有QQ Bridge，那么张小凡就必须申请一个QQ号，然后在QQ中添加QQ好友800003，然后方可和小白通讯。
可是当我们有QQ Bridge后，情况就发生了变化。
张小凡直接在自己UIM帐户[email protected]里面添加好友，指定好友IM为QQ，IM 号为800003。然后UIM服务器就把这个QQ好友添加到张小凡的UIM帐户里了。
那么UIM服务器在后台是如何做这个添加的呢？
首先，UIM服务器随机的选择一个实现申请好的QQ号，比如900001，然后QQ Bridge会通过900001，向QQ服务器申请将800003加为好友。由于在QQ服务器眼里，QQ Bridge实际上是一个QQ客户端，所以，就按照正常手续征询对方同意，当对方同意后，这个好友就倍加到900001这个QQ的好友列表中了。
在UIM服务器中记载了，[email protected]这个帐户有一个QQ好友：800003，而QQ Bridge服务器记载了，他使用的是服务器QQ号900001来和800003进行通讯。
下面张小凡要找小白聊天，于是他双击他好友列表中的小白这个好友，敲了一段文字"hello"。
这个hello会最先被送到UIM服务器，UIM服务器的dispatcher会发现这个消息不是本地的，而是QQ服务器的，于是转发消息到QQ Bridge服务器，QQ Bridge服务器一看，目的地是QQ:800003，而源是[email protected]，于是， QQ Bridge就用QQ:900001这个帐户向800003这个帐户发送消息。
对于800003而言，他只是看到自己收到了一个从900001这个号码发来的消息，而意识不到，这个实际上是一个UIM服务器的帐户。
小白回消息，"I got it"。这个消息会先发送到QQ服务器，QQ一看目的地是900001，于是消息就被分发到900001身上，QQ Bridge就收到了这条回复。然后对比本地表后发现，远程好友是：QQ:800003的，本地QQ是900001的，应该发送给张小凡。于是QQ Bridge和UIM服务器联系，UIM服务器将这个消息传递到张小凡的计算机上。
通过这个描述，大家可能会发现，QQ Bridget非常像网络中的NAT，网络地址转换。而这里，实际上是IM协议转换，非常类似的机制。
通过这种形式，QQ用户和UIM用户可以无缝衔接，他们之间的通讯是透明的，他们意识不到，特别是QQ的用户，自己通讯的对方是另一种协议。
2.3 缺陷
这是一个类NAT的东西，也就面临和NAT一样的问题，就是QQ的好友无法添加UIM的好友，除非做静态映射。也就是说，添加好友的行为，一定是UIM用户添加QQ用户，而无法是QQ用户添加UIM用户。这个其实也是由于QQ不开放的原因。
静态映射可以这样完成。比如张小凡之前曾经有一个QQ号800004，现在他迁移到UIM服务器了，他可以在UIM服务器上注册自己的QQ帐户。这样，所 有800004的好友，自动的加入他UIM的好友。以后，凡是张小凡向QQ好友发消息，那么本地QQ号就不再是原来的900001了，而是张小凡注册的 QQ帐户800004。因此，任何想添加张小凡QQ的人，只要添加800004，那么就自然会出现在张小凡的UIM好友列表里。
通过注册自己已有的QQ号来绑定UIM帐号。即方便了迁移，也方便了QQ添加迁移到UIM用户为好友。
3 UIM服务器联盟
UIM是单一的服务器么？就像QQ, MSN, Google Talk那样由一个大公司来运作，集中管理？
我们可以这样子，其实也可以分布式。就像email服务器那样。下面我就举一个分布式的例子。
3.1 各自为政
假设UIM服务器是可以免费下载的，任何人如果愿意都可以架设UIM服务器，而且由于UIM之间的协议是标准化的，任何人也可以实现自己的兼容UIM服务器。
那么现在，鬼王宗、青云门的大竹峰和小竹峰都建立了自己的IM服务器方便自己的门人通讯。就如下图所示。
在小竹峰下有几个用户，其中两个，一个是田灵儿(tianlinger)，另一个是张小凡(zhangxiaofan)。
如果张小凡想和田灵儿通讯，很简单，就和今天的QQ一样。由于他们都连入了同一个服务器，通过服务器就可以互相通讯了(绿线)，甚至可以直接点对点通讯（黄线）。
3.2 结盟
在初期，各自为政似乎还基本满足。但随着日子的发展，张小凡通过七脉会武结识了陆雪琪师姐。可是小凡没有大竹峰的帐户，小凡始终无法与陆雪琪取得联系。
虽然他们都有自己的IM帐户，但是由于大竹峰和小竹峰的服务器并不交换信息，所以除非张小凡跑到大竹峰去，否则无法和陆雪琪交流。
这种需求不是个例，而是具有普遍性的。田灵儿也还想着和龙首峰的齐昊师兄谈天说地呢。共同的利益，促使了结盟的出现。
如下图所示：
于是有一个叫做Universal IM Union(宇宙IM联盟)出现了。凡是符合UIM服务器间协议标准的服务器都可以加入联盟。而联盟有一个union.uim.com的服务器，负责管理注册、注销和查询UIM服务器。
现在大竹峰和小竹峰的服务器都加入了这个宇宙IM联盟。
这样当大竹峰的服务器需要转发消息到小竹峰的时候，他可以查询union.uim.com，从而得知小竹峰的服务器的位置，反之亦然。服务器互相之间可达了，那么剩下的就是按照标准通讯协议交换消息了。
3.3 通讯
这回张小凡想和同样加入了宇宙IM联盟的鬼王宗服务器用户碧遥联系，他会发送消息到[email protected]。
如下图所示：
小竹峰的服务器一看消息目的地，发现是guiwangzong.com，而不是本地。于是小竹峰的服务器就到union.uim.com上查询，鬼王宗的服务器在哪里。
union查询后，告诉小竹峰的服务器，鬼王宗的服务器在uim.guiwangzong.com。
然后小竹峰的服务器就将张小凡的消息，直接发给uim.guiwangzong.com。
鬼王宗的服务器收到后，一对比，发现目的地是本地帐户碧遥的，于是就将这个信息转发到碧遥的计算机上。
碧遥回复消息也是同样的一个流程。
大家可以注意到，其实union.uim.com实际上是一个dynamic dns。联盟之负责记录各个im服务器的域和服务器的地址。而不负责转发消息。所有的消息交换是由各个UIM服务器之间完成的，联盟服务器不参与信息交换，仅仅起到一个目录查询的作用。
其中可以优化的是，如果所有UIM服务器遵循同样的标准的话，那么张小凡在第一个消息后，就可以从小竹峰的服务器上得知鬼王宗服务器的地址，甚至碧遥计算 机的地址，于是直接向鬼王宗服务器或者碧遥的计算机发送消息，和当前的IM点对点交流是一样的。避免了中间的流程，降低了延时。
4、尾声
感谢大家的提醒。没想到我的这些想法刚好和 Jabber的思路不谋而合，这着实让我兴奋了一会儿，仔细的阅读了 Jabber的简单介绍后，有一种相见恨晚的感觉。
“Jabber是一个开放的、基于 XML的协议。它的用途在 即时通讯及表示信息方面。”
“ Jabber的关键特色是， 分布式的即时通讯系统，以及使用XML串流。”
“ Jabber网络是基于服务器的（即客户端之间彼此不直接交谈），但是也是分布式的。不像 AOL即时通或 MSN Messenger等服务， Jabber没有中央官方服务器。”
“ Jabber系统有一个独特的 网关（也称作传送器）功能，该功能允许用户可以使用其他协议，如 AOL、 ICQ、 MSN、 Yahoo、 短信或者 电子邮件。和 Trillian或 Gaim等其他多协议客户端不同的是，Jabber在服务器级别提供这个功能，任何Jabber用户都可以注册一个这样的网关来登录其他网络。也就是说任何支持Jabber协议的客户端都可以访问一个存在的网关，来与其他网络上的用户联系。”
Jabber具有如下特点：
第一个案例和Jabber中的网关很相似，用以融合其他多种协议，不单单是其他IM协议，也可以是SMS或者Email。第二个案例则和Jabber整体的思想很接近，是基于服务器的IM，而不是基于集中管理的IM，这种非集中管理的方式，是认证域最小化，有助于安全性的提升，另外也给服务器的区域组织提供了更好的灵活性。这也更证明了我的思路的方向是对的。开放、互联是必然趋势，分布式服务器机制更灵活的对IM网络进行组织，并且更好的提升了局部安全性，因为缩小了信任域。
而此时另一个名字又出现在眼前 － Google。此前一直不理解为什么 Google Talk采用Jabber协议，也没有主动去了解Jabber协议具体内容，仅当其为一个普通的IM协议而已。而 如今，在了解了Jabber的思路后，再对我比前面的分布与互通的想法，再一次感叹Google的大气和眼光之长远。开放的、标准化的、分布式服务器的、基于XML的、 可以支持其它协议联通能力的、具有良好扩展能力的Jabber，确实是一个很好的选择。虽然在今天Google Talk尚显幼稚，但是从底层的Jabber已经可以小窥其野心和它未来的良好的潜力。期待着未来有一日，Google能够成功的推动各大IM的互联，结束当今IM的信息孤岛的局面。祝 Google与 Jabber越做越好。
推荐读物：
维基大百科全书：
http://en.wikipedia.org/wiki/Jabber
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
于XMPP通讯协议相关的RFC：
RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922, Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
Jabber 官方网站：
http://www.jabber.org/
http://www.jabber.org/jeps/
当前IM的站场上依旧硝烟弥漫，QQ, MSN, Google Talk, ICQ, Yahoo!还都在争夺着市场的份额。今天我所要说的，是跳出商业利益趋势之短利，而从长远的角度考虑IM的发展趋势。
目前各大IM各自为政，在互相学习中提供着越来越丰富的功能。在他们疯狂的瓜分着internet用户市场的时候，我们普通的用户成了他们商业竞争的受害 人。恕不见，因为自己的朋友有着不同的IM，为了与他们通讯，我们只好自己申请成为那个IM的用户。结果，每个人一开机，就有着少则3－4个IM同时叮叮 咚咚的启动，多则6－7个。
虽然也有着多合一的IM客户端，但是一来有些功能由于这种整合客户端所限，我们无法使用；二来，我们依旧需要管理着越来越多的帐户和密码。不少人因为犯懒，而多个帐户使用一个密码，结果导致一个密码被人知道后，其他的密码也被人家猜到了，而使信息泄密。
如何让用户面对一个简单的界面，用最少的用户名密码对完成所必须的IM通讯呢？
现今的世界，唯有开放，方能生存。
我的想法是各个IM服务器之间互连，不要再那么封闭了。IM服务器遵循某种标准的IM通讯协议，然后就像email服务器那样，虽然IM服务器不同，IM的服务不同，但是他们之间可以共享最基本的消息通讯。
这样QQ的用户可以添加MSN的好友，并且可以与MSN的好友交流，而不必非注册一个MSN帐户。各个IM服务提供商，由IM孤岛，变成了IM接入点，所 有的IM孤岛互联，组成一个IM的服务器网络，或者世界。成为任何一个IM的用户，都可以与这个IM世界里的任何服务器的任何用户交流，而无须非在对方的 IM服务器上注册用户。
其实这种思想在Email身上有很好的体现。虽然大家的email服务器不同，注册的服务不同。但是我们依旧可以和不同的email服务器上用户通讯，而不必非得在对方的email服务器上注册一个用户。
如果从email的视角看今天的IM的话，那么称今天的IM为IM孤岛(IM Island)，一点都不为过。未来是互联而开放的世界，任何孤岛都会被打破，互联是一种必然的趋势。
其实抽象一下IM，虽然IM的功能五花八门，但是我们90%以上的时间就是在使用下面这几个公共的特性：
- 文字消息交流 (包括表情和图片)
- 语音、视频交流
- 群(组)交流
- 好友管理(包括好友组管理，好友的添加删除，以及好友信息或者blog页面)
- 游戏娱乐平台
- email提醒
- 各种消息
以这个通用的协议为基础，所有加入IM World的IM服务器，必须遵守这个通用IM协议，并采用这个协议互相通讯。就可以完成IM世界里面基本交流无障碍。当然，IM服务商，会除这个通用协 议中要求的这些特性外，提供更多额外的服务给用户，以吸引用户使用自己的IM作为IM World的接入点。
互联导致IM用户群的整合，对于任何的IM服务商，都是用户群的扩大，由于共同制定和完善通用IM标准，也会使标准更加完善，通讯更稳定。
这是考验一个公司和决策人气魄和胆识的时候。不同的公司和决策人会作出不同的反应。
到底是给自己的用户加上沉重的枷锁，关起门来不让他们跑掉？还是摆出自信和开放的姿态，敞开大门，欢迎其他的IM与自己的消息互通？
并不是所有的人都能够真正的把目光放长远，能够作出开放的姿态的。但是，趋势是一定的，已经有一些小范围的消息互通，但是还不足够。让我们拭目以待，看看谁是这个敢吃螃蟹的人，让这个世界的IM成功的互联起来。
我下面就说两种互通的例子，第一个是一个开放的IM服务器和一个封闭的IM服务器，目前以QQ为例，通过QQ Bridge，或者叫做QQ网关，进行互通的例子。第二个，是让IM服务器分布式，类似于email和dns那样，im服务器同联盟服务器通讯，使得不同 的IM用户可以互相通讯。
2、可以添加QQ好友，并且可以与QQ好友通讯的IM服务器
2.1 背景
在这个图中，800001 - 800002是QQ用户，他们使用自己的计算机，分别连接QQ不同的服务器。而Universal IM服务器则是另一个IM服务商，我们虚构一个名字叫做Universal IM，简称(UIM)。属于这个IM服务商的有[email protected]， [email protected], [email protected]这3个用户。
QQ Bridge 服务器，实际上是一个虚拟的多个QQ客户端的服务器，当前他有两个QQ帐户，一个是900001，另一个是900002。
当我们忽略掉QQ Bridge服务器的时候，这就是典型的两个IM服务商，他们拥有自己的用户群，而这些用户群中的用户不可以跨群访问。也就是说800001永远无法和 [email protected]取得联系，无论是加好友还是发消息都不行。
这就是我们目前大部分IM的现状。
我的想法是，在UIM服务器和QQ服务器中间建立起一个桥梁。由于QQ的思想并不开放，所以，我们将这个QQ Bridge服务器放在靠近UIM的位置，并且将其视为UIM服务器的一个子模块。当然，如果QQ是开放的，那么这个QQ Bridge就要改名为QQ-UIM Gateway了，并且独立出来，做QQ服务器和UIM服务器的消息路由。
暂且，我们先将其视为UIM的一个模块（毕竟这符合QQ当前的封闭策略）。
首先，UIM管理人员，申请若干个合法的QQ帐户，在此例子中，是900001, 900002。
2.2 通讯过程
背景清楚后，通讯过程就比较好理解了。假设zhangxiaofan（张小凡）这个用户有一个好友小白，那个好友的QQ号是800003。如果没有QQ Bridge，那么张小凡就必须申请一个QQ号，然后在QQ中添加QQ好友800003，然后方可和小白通讯。
可是当我们有QQ Bridge后，情况就发生了变化。
张小凡直接在自己UIM帐户[email protected]里面添加好友，指定好友IM为QQ，IM 号为800003。然后UIM服务器就把这个QQ好友添加到张小凡的UIM帐户里了。
那么UIM服务器在后台是如何做这个添加的呢？
首先，UIM服务器随机的选择一个实现申请好的QQ号，比如900001，然后QQ Bridge会通过900001，向QQ服务器申请将800003加为好友。由于在QQ服务器眼里，QQ Bridge实际上是一个QQ客户端，所以，就按照正常手续征询对方同意，当对方同意后，这个好友就倍加到900001这个QQ的好友列表中了。
在UIM服务器中记载了，[email protected]这个帐户有一个QQ好友：800003，而QQ Bridge服务器记载了，他使用的是服务器QQ号900001来和800003进行通讯。
- 远程好友: QQ:800003
- 本地QQ: 900001
- 本地帐户: [email protected]
下面张小凡要找小白聊天，于是他双击他好友列表中的小白这个好友，敲了一段文字"hello"。
这个hello会最先被送到UIM服务器，UIM服务器的dispatcher会发现这个消息不是本地的，而是QQ服务器的，于是转发消息到QQ Bridge服务器，QQ Bridge服务器一看，目的地是QQ:800003，而源是[email protected]，于是， QQ Bridge就用QQ:900001这个帐户向800003这个帐户发送消息。
对于800003而言，他只是看到自己收到了一个从900001这个号码发来的消息，而意识不到，这个实际上是一个UIM服务器的帐户。
小白回消息，"I got it"。这个消息会先发送到QQ服务器，QQ一看目的地是900001，于是消息就被分发到900001身上，QQ Bridge就收到了这条回复。然后对比本地表后发现，远程好友是：QQ:800003的，本地QQ是900001的，应该发送给张小凡。于是QQ Bridge和UIM服务器联系，UIM服务器将这个消息传递到张小凡的计算机上。
通过这个描述，大家可能会发现，QQ Bridget非常像网络中的NAT，网络地址转换。而这里，实际上是IM协议转换，非常类似的机制。
通过这种形式，QQ用户和UIM用户可以无缝衔接，他们之间的通讯是透明的，他们意识不到，特别是QQ的用户，自己通讯的对方是另一种协议。
2.3 缺陷
这是一个类NAT的东西，也就面临和NAT一样的问题，就是QQ的好友无法添加UIM的好友，除非做静态映射。也就是说，添加好友的行为，一定是UIM用户添加QQ用户，而无法是QQ用户添加UIM用户。这个其实也是由于QQ不开放的原因。
静态映射可以这样完成。比如张小凡之前曾经有一个QQ号800004，现在他迁移到UIM服务器了，他可以在UIM服务器上注册自己的QQ帐户。这样，所 有800004的好友，自动的加入他UIM的好友。以后，凡是张小凡向QQ好友发消息，那么本地QQ号就不再是原来的900001了，而是张小凡注册的 QQ帐户800004。因此，任何想添加张小凡QQ的人，只要添加800004，那么就自然会出现在张小凡的UIM好友列表里。
通过注册自己已有的QQ号来绑定UIM帐号。即方便了迁移，也方便了QQ添加迁移到UIM用户为好友。
3 UIM服务器联盟
UIM是单一的服务器么？就像QQ, MSN, Google Talk那样由一个大公司来运作，集中管理？
我们可以这样子，其实也可以分布式。就像email服务器那样。下面我就举一个分布式的例子。
3.1 各自为政
假设UIM服务器是可以免费下载的，任何人如果愿意都可以架设UIM服务器，而且由于UIM之间的协议是标准化的，任何人也可以实现自己的兼容UIM服务器。
那么现在，鬼王宗、青云门的大竹峰和小竹峰都建立了自己的IM服务器方便自己的门人通讯。就如下图所示。
鬼王宗的服务器是： uim.guiwangzong.com
大竹峰：uim.dazhufeng.qingyunmen.com
小竹峰：uim.xiaozhufeng.qingyunmen.com
大竹峰：uim.dazhufeng.qingyunmen.com
小竹峰：uim.xiaozhufeng.qingyunmen.com
在小竹峰下有几个用户，其中两个，一个是田灵儿(tianlinger)，另一个是张小凡(zhangxiaofan)。
如果张小凡想和田灵儿通讯，很简单，就和今天的QQ一样。由于他们都连入了同一个服务器，通过服务器就可以互相通讯了(绿线)，甚至可以直接点对点通讯（黄线）。
3.2 结盟
在初期，各自为政似乎还基本满足。但随着日子的发展，张小凡通过七脉会武结识了陆雪琪师姐。可是小凡没有大竹峰的帐户，小凡始终无法与陆雪琪取得联系。
虽然他们都有自己的IM帐户，但是由于大竹峰和小竹峰的服务器并不交换信息，所以除非张小凡跑到大竹峰去，否则无法和陆雪琪交流。
这种需求不是个例，而是具有普遍性的。田灵儿也还想着和龙首峰的齐昊师兄谈天说地呢。共同的利益，促使了结盟的出现。
如下图所示：
于是有一个叫做Universal IM Union(宇宙IM联盟)出现了。凡是符合UIM服务器间协议标准的服务器都可以加入联盟。而联盟有一个union.uim.com的服务器，负责管理注册、注销和查询UIM服务器。
现在大竹峰和小竹峰的服务器都加入了这个宇宙IM联盟。
这样当大竹峰的服务器需要转发消息到小竹峰的时候，他可以查询union.uim.com，从而得知小竹峰的服务器的位置，反之亦然。服务器互相之间可达了，那么剩下的就是按照标准通讯协议交换消息了。
3.3 通讯
这回张小凡想和同样加入了宇宙IM联盟的鬼王宗服务器用户碧遥联系，他会发送消息到[email protected]。
如下图所示：
小竹峰的服务器一看消息目的地，发现是guiwangzong.com，而不是本地。于是小竹峰的服务器就到union.uim.com上查询，鬼王宗的服务器在哪里。
union查询后，告诉小竹峰的服务器，鬼王宗的服务器在uim.guiwangzong.com。
然后小竹峰的服务器就将张小凡的消息，直接发给uim.guiwangzong.com。
鬼王宗的服务器收到后，一对比，发现目的地是本地帐户碧遥的，于是就将这个信息转发到碧遥的计算机上。
碧遥回复消息也是同样的一个流程。
大家可以注意到，其实union.uim.com实际上是一个dynamic dns。联盟之负责记录各个im服务器的域和服务器的地址。而不负责转发消息。所有的消息交换是由各个UIM服务器之间完成的，联盟服务器不参与信息交换，仅仅起到一个目录查询的作用。
其中可以优化的是，如果所有UIM服务器遵循同样的标准的话，那么张小凡在第一个消息后，就可以从小竹峰的服务器上得知鬼王宗服务器的地址，甚至碧遥计算 机的地址，于是直接向鬼王宗服务器或者碧遥的计算机发送消息，和当前的IM点对点交流是一样的。避免了中间的流程，降低了延时。
4、尾声
感谢大家的提醒。没想到我的这些想法刚好和 Jabber的思路不谋而合，这着实让我兴奋了一会儿，仔细的阅读了 Jabber的简单介绍后，有一种相见恨晚的感觉。
“Jabber是一个开放的、基于 XML的协议。它的用途在 即时通讯及表示信息方面。”
“ Jabber的关键特色是， 分布式的即时通讯系统，以及使用XML串流。”
“ Jabber网络是基于服务器的（即客户端之间彼此不直接交谈），但是也是分布式的。不像 AOL即时通或 MSN Messenger等服务， Jabber没有中央官方服务器。”
“ Jabber系统有一个独特的 网关（也称作传送器）功能，该功能允许用户可以使用其他协议，如 AOL、 ICQ、 MSN、 Yahoo、 短信或者 电子邮件。和 Trillian或 Gaim等其他多协议客户端不同的是，Jabber在服务器级别提供这个功能，任何Jabber用户都可以注册一个这样的网关来登录其他网络。也就是说任何支持Jabber协议的客户端都可以访问一个存在的网关，来与其他网络上的用户联系。”
Jabber具有如下特点：
开放— Jabber协定是自由、开放、公开的，并且易于了解。而且在客户端、服务器、元件、源码库等方面，都已经各自有多种实作。
标准— 因特网工程工作小组（IETF）已经将Jabber的核心XML串流协定以XMPP之名，正式列为认可的即时通讯及Presence技术。而XMPP的技术规格已被出版为RFC 3920及RFC 3921。
证实可用— 第一个Jabber技术是Jeremie Miller在1998年开发的，现在已经相当稳定；数以百计的开发者为Jabber技术而努力。今日的因特网上有数以万计的Jabber服务器运作著，并有数以百万计的人们使用Jabber即时传讯软件。
分布式— Jabber网络的架构和电子邮件十分相像；因此任何人都可以运行自己的Jabber服务器，使个人及组织能够掌控他们的即时传讯体验。
安全— 任何Jabber服务器可以独立于公众Jabber网络（例如在企业内部网络中），而使用SASL及TLS等技术的可靠安全性，已内建于核心XMPP技术规格中。
可扩展— XML命名空间的威力可使任何人在核心协定的基础上建造客制化的功能；为了维持通透性，常见的扩充套件由Jabber软件基金会管理。
弹性佳— Jabber除了可用在即时通讯的应用程序，还能用在网络管理、内容供稿、协同工具、档案共享、游戏、远端系统监控等。
多样性— 用Jabber协定来建造及布署即时应用程序及服务的公司及开放源码计划分布在各种领域；用Jabber技术开发软件，资源及支援的来源是多样的，使得使你不会陷于被“绑架”的困境。
－－ 摘自《维基大百科全书：中文》
第一个案例和Jabber中的网关很相似，用以融合其他多种协议，不单单是其他IM协议，也可以是SMS或者Email。第二个案例则和Jabber整体的思想很接近，是基于服务器的IM，而不是基于集中管理的IM，这种非集中管理的方式，是认证域最小化，有助于安全性的提升，另外也给服务器的区域组织提供了更好的灵活性。这也更证明了我的思路的方向是对的。开放、互联是必然趋势，分布式服务器机制更灵活的对IM网络进行组织，并且更好的提升了局部安全性，因为缩小了信任域。
而此时另一个名字又出现在眼前 － Google。此前一直不理解为什么 Google Talk采用Jabber协议，也没有主动去了解Jabber协议具体内容，仅当其为一个普通的IM协议而已。而 如今，在了解了Jabber的思路后，再对我比前面的分布与互通的想法，再一次感叹Google的大气和眼光之长远。开放的、标准化的、分布式服务器的、基于XML的、 可以支持其它协议联通能力的、具有良好扩展能力的Jabber，确实是一个很好的选择。虽然在今天Google Talk尚显幼稚，但是从底层的Jabber已经可以小窥其野心和它未来的良好的潜力。期待着未来有一日，Google能够成功的推动各大IM的互联，结束当今IM的信息孤岛的局面。祝 Google与 Jabber越做越好。
推荐读物：
维基大百科全书：
http://en.wikipedia.org/wiki/Jabber
http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
于XMPP通讯协议相关的RFC：
RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core
RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 3922, Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
Jabber 官方网站：
http://www.jabber.org/
http://www.jabber.org/jeps/