[已回复] 关于RainbowChat中礼品发送的逻辑疑问

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

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

今天出门办事了 晚点回复你

引用：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
“但如果此时判定对方在线，则实时发送出去，此时就可能无法实时送达成功，但并不会产生丢包，只是会在发送 ...

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