XMPP添加好友相关文章一篇
2012-09-13 15:10
375 查看
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集成中兼容性的一点小问题.
假定 user@jabbercn.org 使用 psi , 而 contact@rooyee.biz 使用 rooyee messenger ,情形如下:
1. contact@rooyee.biz 向 user@jabbercn.org 发出添加好友的请求
<iq id="rosterset1" type="set">
<query xmlns="jabber:iq:roster">
<item jid="user@jabbercn.org" name="user"/>
</query>
</iq>
<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribe"/>
2. user@jabbercn.org 向 contact@rooyee.biz 发出添加好友请求(也就是请求对方加自己为好友)
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>
3. user@jabbercn.org 同意成为 contact@rooyee.biz 的好友(也就是批准对方添加自己)
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribed"/>
4. contact@rooyee.biz 同意 成为user@jabbercn.org 的好友(也就是批准对方添加自己)
<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribed"/>
在RFC3921第八章:名册条目和出席信息订阅的集成中规定, 正常的用户之间的相互订阅中,本方接收到对方请求之后,首先要做的是批准对方请求,然后才是向对方提出订阅请求, 而在上述例子中,psi客户端(也就是用户user@jabbercb.org)是把这两步颠倒过来的(第二步和第三步).
现在兼容性的问题就来了, jabberd2服务器是严格按照RFC3921第八章:名册条目和出席信息订阅的集成来实现的,使用psi的user@jabbercn.org在批准contact@rooyee.biz之前就向对方请求订阅,导致最后user@jabbercn.org的状态是From,而contact@rooyee.biz状态则为Both, 也就是说 user@jabbercn.org 无法正常完成添加好友功能.
然后我们再来看看RFC3921第九章订阅状态中规定, 如果单从订阅状态考虑, 那么psi的处理方式并非那么无理. 我们看看每一步动作之后双方的状态改变情况(以下每一步的状态对应前述例子的每一步):
1. user@jabbercn.org : None + Pending In
contact@rooyee.biz : None + Pending Out
2. user@jabbercn.org : None + Pending In/Out
contact@rooyee.biz : None + Pending Out/In
3. user@jabbercn.org : From + Pending Out
contact@rooyee.biz : To + Pending In
4. user@jabbercn.org : Both
contact@rooyee.biz : Both
openfire中就是这样单纯按订阅状态处理的, 所以psi客户端和openfire服务器配合的时候可以正常地添加好友.
接下来我们再看RFC3921第六章的管理订阅和RFC3921第七章的名册管理, 如果不考虑集成的问题, 把相互加好友变成你加我加上我加你,那么就需要把前述的例子的第二步改成如下
2. user@jabbercn.org向contact@rooyee.biz发出添加好友请求(也就是请求对方加自己为好友)
<iq id="rosterset2" type="set">
<query xmlns="jabber:iq:roster">
<item jid="contact@rooyee.biz" name="contact"/>
</query>
</iq>
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>
pandion客户端就是采用这个处理方式, 它和目前的服务器都可以很好地兼容.
综上所述, RFC3921的第六章第七章是把出席信息订阅和名册管理分开考虑的, 因为在XMPP中是允许存在独立的出席信息应用的,所以从逻辑上来讲它们是独立的, 第八章则考虑到了它们的集成,这是大部分XMPP应用中的典型需求, 第九章基于订阅状态处理的规则对于第八章的优化, 它侧重于使得服务器实现更加简单和易于兼容.
[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集成中兼容性的一点小问题.
假定 user@jabbercn.org 使用 psi , 而 contact@rooyee.biz 使用 rooyee messenger ,情形如下:
1. contact@rooyee.biz 向 user@jabbercn.org 发出添加好友的请求
<iq id="rosterset1" type="set">
<query xmlns="jabber:iq:roster">
<item jid="user@jabbercn.org" name="user"/>
</query>
</iq>
<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribe"/>
2. user@jabbercn.org 向 contact@rooyee.biz 发出添加好友请求(也就是请求对方加自己为好友)
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>
3. user@jabbercn.org 同意成为 contact@rooyee.biz 的好友(也就是批准对方添加自己)
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribed"/>
4. contact@rooyee.biz 同意 成为user@jabbercn.org 的好友(也就是批准对方添加自己)
<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribed"/>
在RFC3921第八章:名册条目和出席信息订阅的集成中规定, 正常的用户之间的相互订阅中,本方接收到对方请求之后,首先要做的是批准对方请求,然后才是向对方提出订阅请求, 而在上述例子中,psi客户端(也就是用户user@jabbercb.org)是把这两步颠倒过来的(第二步和第三步).
现在兼容性的问题就来了, jabberd2服务器是严格按照RFC3921第八章:名册条目和出席信息订阅的集成来实现的,使用psi的user@jabbercn.org在批准contact@rooyee.biz之前就向对方请求订阅,导致最后user@jabbercn.org的状态是From,而contact@rooyee.biz状态则为Both, 也就是说 user@jabbercn.org 无法正常完成添加好友功能.
然后我们再来看看RFC3921第九章订阅状态中规定, 如果单从订阅状态考虑, 那么psi的处理方式并非那么无理. 我们看看每一步动作之后双方的状态改变情况(以下每一步的状态对应前述例子的每一步):
1. user@jabbercn.org : None + Pending In
contact@rooyee.biz : None + Pending Out
2. user@jabbercn.org : None + Pending In/Out
contact@rooyee.biz : None + Pending Out/In
3. user@jabbercn.org : From + Pending Out
contact@rooyee.biz : To + Pending In
4. user@jabbercn.org : Both
contact@rooyee.biz : Both
openfire中就是这样单纯按订阅状态处理的, 所以psi客户端和openfire服务器配合的时候可以正常地添加好友.
接下来我们再看RFC3921第六章的管理订阅和RFC3921第七章的名册管理, 如果不考虑集成的问题, 把相互加好友变成你加我加上我加你,那么就需要把前述的例子的第二步改成如下
2. user@jabbercn.org向contact@rooyee.biz发出添加好友请求(也就是请求对方加自己为好友)
<iq id="rosterset2" type="set">
<query xmlns="jabber:iq:roster">
<item jid="contact@rooyee.biz" name="contact"/>
</query>
</iq>
<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>
pandion客户端就是采用这个处理方式, 它和目前的服务器都可以很好地兼容.
综上所述, RFC3921的第六章第七章是把出席信息订阅和名册管理分开考虑的, 因为在XMPP中是允许存在独立的出席信息应用的,所以从逻辑上来讲它们是独立的, 第八章则考虑到了它们的集成,这是大部分XMPP应用中的典型需求, 第九章基于订阅状态处理的规则对于第八章的优化, 它侧重于使得服务器实现更加简单和易于兼容.
相关文章推荐
- 网页实现多文件下载,貌似不行。这里有一篇相关的文章
- scratchbox添加工具链的一篇文章
- phpcms v9后台添加文章时选择相关文章可调用其它模型信息的方法
- xmpp获取好友信息和添加删除好友(4)
- [置顶] XMPPFrameWork IOS 开发(五)获取好友信息和添加删除好友
- XMPP系列(三)---获取好友列表、添加好友
- 九度OJ-1439:Least Common Multiple(相关文章尚未添加)
- hadoop相关的一篇文章
- Android xmpp开发 asmack获取离线在线添加好友消息 及 好友上线下线通知
- XMPP系列(三)---获取好友列表、添加好友
- iOSXMPP登录、添加好友、退出
- hexo 新建一篇文章给它添加分类和标签:
- 搬来一篇直播,视频相关理解的文章
- iOS XMPP研究探索:添加好友
- xmpp 添加用户 添加好友请求 删除好友
- 一篇整理比较好的算法相关文章 Java语言
- 准备写一篇调试器相关的文章
- 使用solrj添加文档,导入包,之后的代码实现,接上一篇文章
- XMPP-好友列表模块的注册和好友列表获取,添加,删除
- XMPP之添加好友请求报文