XMPP添加好友相关文章一篇
http://jingyan.info/xmpp%E6%B7%BB%E5%8A%A0%E5%A5%BD%E5%8F%8B%E7%9B%B8%E5%85%B3%E6%96%87%E7%AB%A0%E4%B8%80%E7%AF%87/
[xmpp][添加好友]rfc3921中presence和roster集成的一点思考
[xmpp][添加好友]rfc3921中presence和roster集成的一点思考
Jabber(XMPP)中文翻译计划
http://wiki.jabbercn.org/space/start/2007-05-03/1
————————————————–
[ 开始 | 索引 | 登录 或 注册 | 忘记密码 ]
start > 2007-05-03 > 1
2007-05-03 #1
由how创建。最后一次被how修改，在1年1天之前。 被访问了 459 次。 #1
[编辑] [rdf]
标签
附件
rfc3921中presence和roster集成的一点思考
最近发现psi的添加联系人功能和别的客户端软件有一点小小不同, 也暴露出RFC3921中presence和roster集成中兼容性的一点小问题.
假定 [email protected] 使用 psi , 而 [email protected] 使用 rooyee messenger ,情形如下:
1. [email protected] 向 [email protected] 发出添加好友的请求
<iq id="rosterset1" type="set">
<query xmlns="jabber:iq:roster">
<item jid="[email protected]" name="user"/>
</query>
</iq>
<presence from="[email protected]" to="[email protected]" type="subscribe"/>
2. [email protected] 向 [email protected] 发出添加好友请求(也就是请求对方加自己为好友)
<presence from="[email protected]" to="[email protected]" type="subscribe"/>
3. [email protected] 同意成为 [email protected] 的好友(也就是批准对方添加自己)
<presence from="[email protected]" to="[email protected]" type="subscribed"/>
4. [email protected] 同意 成为[email protected] 的好友(也就是批准对方添加自己)
<presence from="[email protected]" to="[email protected]" type="subscribed"/>
在RFC3921第八章:名册条目和出席信息订阅的集成中规定, 正常的用户之间的相互订阅中,本方接收到对方请求之后,首先要做的是批准对方请求,然后才是向对方提出订阅请求, 而在上述例子中,psi客户端(也就是用户[email protected])是把这两步颠倒过来的(第二步和第三步).
现在兼容性的问题就来了, jabberd2服务器是严格按照RFC3921第八章:名册条目和出席信息订阅的集成来实现的,使用psi的[email protected]在批准[email protected]之前就向对方请求订阅,导致最后[email protected]的状态是From,而[email protected]状态则为Both, 也就是说 [email protected] 无法正常完成添加好友功能.
然后我们再来看看RFC3921第九章订阅状态中规定, 如果单从订阅状态考虑, 那么psi的处理方式并非那么无理. 我们看看每一步动作之后双方的状态改变情况(以下每一步的状态对应前述例子的每一步):
1. [email protected] : None + Pending In
[email protected] : None + Pending Out
2. [email protected] : None + Pending In/Out
[email protected] : None + Pending Out/In
3. [email protected] : From + Pending Out
[email protected] : To + Pending In
4. [email protected] : Both
[email protected] : Both
openfire中就是这样单纯按订阅状态处理的, 所以psi客户端和openfire服务器配合的时候可以正常地添加好友.
接下来我们再看RFC3921第六章的管理订阅和RFC3921第七章的名册管理, 如果不考虑集成的问题, 把相互加好友变成你加我加上我加你,那么就需要把前述的例子的第二步改成如下
2. [email protected]向[email protected]发出添加好友请求(也就是请求对方加自己为好友)
<iq id="rosterset2" type="set">
<query xmlns="jabber:iq:roster">
<item jid="[email protected]" name="contact"/>
</query>
</iq>
<presence from="[email protected]" to="[email protected]" type="subscribe"/>
pandion客户端就是采用这个处理方式, 它和目前的服务器都可以很好地兼容.
综上所述, RFC3921的第六章第七章是把出席信息订阅和名册管理分开考虑的, 因为在XMPP中是允许存在独立的出席信息应用的,所以从逻辑上来讲它们是独立的, 第八章则考虑到了它们的集成,这是大部分XMPP应用中的典型需求, 第九章基于订阅状态处理的规则对于第八章的优化, 它侧重于使得服务器实现更加简单和易于兼容.