请选择 进入手机版 | 继续访问电脑版

默认
发表评论 8
[已回复] 关于RainbowChat中礼品发送的逻辑疑问
RainbowChat的代码注释:
// 【1目前礼品处理基本逻辑是】:在发送方发出礼品前,先提交服务端进行处理(处理礼品发送的记录和数
// 据(包括减发送者的积分)等),只有等到处理成功才将真正的礼品消息发送给接收方。
// 【2目前逻辑可能存的问题是】:如果发送方提交服务端处理成功(积分减了、记录也插入了db等),但因
// 发送方、接收方、IM中转服务器等任何一个环节的UDP丢包(基于目前的QoS机制无法保证非分非送达到接收方)
// ,都将使得接收方无法收到礼品(发送方看到的可能是消息失败),但实际上发送方却实已经发出来了。
// 【3因逻辑问题带来的影响是】:目前的影响仅可能是接收方无法通过实时消息收到、发送方看到的可能是发送
// 失败等,好在服务端的发送记录、积分处理等账目功能是绝对保证ok的,至少用户在重新登陆时可以查看的到(
// 接收方不会错过的,在我的背包里是可以看到的)。目前没有更好地方法规避这个问题,先这样吧!!!!!!!!!!

1、客户端A向服务端提交数据处理后,客户端A直接向客户端B发送消息,这样理解对不对?
2、如果1理解正确的话,那么,当客户端B为离线状态时,理应发送失败,但实测时可以发送的,那么,对离线消息是怎么处理的?
3、既然存在离线消息处理机制,那么注释中2、3的问题就不应该存在啊

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:RainbowChat
上一篇:RainbowChat[标准版] 的v4.4版已发布!下一篇:[已回复]求教程一下RainbowChat里的这几个情况是bug还是什么?
推荐方案
评论 8
2 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 6 个月前 来自手机 | 显示全部楼层
今天出门办事了 晚点回复你
引用:JackJiang 发表于 2018-10-20 10:52
今天出门办事了 晚点回复你

好的。刚才查看服务端运行log,找到了离线消息处理机制。
1、是否可以这样理解:客户端B在线情况下消息是A to B点对点发送,不经过服务端。
离线消息是由服务端转发。
离线消息比实时消息更有保障,因为离线消息时,服务端会处理客户端B接收消息的返回状态,如未成功会反复发送?
2、但从服务端运行日志看,又好像在线状态下实时消息也不是点对点不经服务端的发送,而是服务端的转发,有一个发送请求和一个应答请求。只不过,服务端不向客户端A反馈转发结果。但这个转发结果服务端是知道的,那么理应有失败重发机制。c2c下客户端A和B会另外向服务端发送以finger为标识符的发、收结果?
3、但从客户端代码看,是通过udpsender点对点发送的。
查找老帖子相关内容:

“即时通讯网注:实际上IM中,数据通讯层无论用的是UDP还是TCP协议,都同样需要消息送达保证(即QoS)机制,原因在于IM的通信是A端-Server-B端的3方通信,而非传统C/S或B/S这种2方通信。

即时通讯网注:一个应用层即时通讯消息的可靠投递,共涉及6个报文,这就是im系统中消息投递的最核心技术(如果某个im系统不包含这6个报文,不要谈什么消息的可靠性)。”

RainbowChat的礼品消息也是3方通信,6个报文?
引用:freeman 发表于 2018-10-20 17:02
查找老帖子相关内容:

“即时通讯网注:实际上IM中,数据通讯层无论用的是UDP还是TCP协议,都同样需要消 ...

没这么复杂:因为礼品的积分处理是调用http接口、而礼品的实时消息是通过IM socket通道,两个不同的通道,所以分成两个步骤,仅此而已。

至少你说的既然存在离线处理,那就能从理论上保证百分之百送达:这个理论肯定是错误的,因为离线还是在线发,是根据对方是否在线来判定的(在线状态的记录在对方APP非正常退出:比如崩溃、被系统硬杀等,这个在线状态就存在一个超时的时间误差),但如果此时判定对方在线,则实时发送出去,此时就可能无法实时送达成功,但并不会产生丢包,只是会在发送方这边显示没有实时发送成功(出现那个红色的感叹号图标)。

这个问题不用纠结,腾讯的设计目标也同样是万有一失这个思路,实时通信是异步非百分非可靠,这是肯定的。
另外,礼品的实时消息跟其它所有消息一样,没有也没有必要特殊处理,所以它的QoS逻辑是一样的。


还有:这个礼物的消息,其实只是个“实时通知”,你这么理更恰当。就像你在网上注册个账号或买个什么东西,理论上会发个短信或邮件通知你,但邮件或短信通知可能因运营商原因,没有成功通知到,但这也只是没有通知到而已,实际上的事情已经做了(金该花的已经花了,事情该做的已经做了)。
签名: 今天天气不好
3方通讯,6个报文,重发、去重机制都具备?

“比如崩溃、被系统硬杀等,这个在线状态就存在一个超时的时间误差),但如果此时判定对方在线,则实时发送出去,此时就可能无法实时送达成功”

误判在线的情况下发送出去,但不会收到后半场的ack的R/A/N三个报文,那么会启动重发机制,从程序的角度来说,也是不存在问题的啊,至于客户端B仍无法收到消息,那就是客户端B自身的问题了,不是该我们处理的,是客户端B的用户该处理的。

之所以研究这些,是准备仿照礼品功能做一个涉及钱的模块进去,所以想搞明白整个流程,从程序的角度杜绝bug,至于外部因素就不考虑了。


例如:A向B转账100,服务端已经扣款,而A得到的反馈是发送失败,那么A重新向B转账,这就造成A的损失。


我就是想确认一下,对礼品流程照猫画虎,有没有问题。


引用:freeman 发表于 2018-10-20 21:54
3方通讯,6个报文,重发、去重机制都具备?

“比如崩溃、被系统硬杀等,这个在线状态就存在一个超时的 ...

是的,就是你理解的这样,但你看到的这段注释是代码洁癖的人写给自已看的,没有其它意义,
签名: 今天天气不好
“但如果此时判定对方在线,则实时发送出去,此时就可能无法实时送达成功,但并不会产生丢包,只是会在发送方这边显示没有实时发送成功(出现那个红色的感叹号图标)”。

此时红色叹号的出现是不是不合适?比如会误导用户A重新发一份礼品给B。

那么,修改为:无论在线离线,也不管服务端向B发没发出,不管B收没收到,只要服务端进行积分处理了,反馈给A的就是成功。红色叹号仅在服务端处理积分失败时显示。
引用:freeman 发表于 2018-10-20 23:03
“但如果此时判定对方在线,则实时发送出去,此时就可能无法实时送达成功,但并不会产生丢包,只是会在发送 ...

是的,可以这样。遗留的这些积分代码,是以前我创业产品里的,本来早准备删掉的,但只是想留下来做功能演示,所以也就保留了下来,但有些逻辑有历史原因,可能并不严谨,你按照你的业务逻辑和数据一致性要求来改或重新开发即可。建议,这样的遗留代码能用的就用,不能用的话,你参考思路,自已写也行,这样你还能更好的掌控你所实现的功能。
签名: 今天天气不好
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部