如何保证即时通讯聊天里消息唯一，后台丢包不重复处理

我说的消息唯一性，是指同一条消息不会被后台处理多次。
比如MobileIMSDK，是基于UDP的，手机向后台发送消息后，后台需要向手机发送回执。由于UDP是不可靠的，有可能后台向手机发送的回执，手机没有收到，于是手机又再次把同一条消息发送给后台。这时候，后台其实是两次接收和处理了同一条消息。
请问这种情况如何处理？
有没有可能在手机端解决这个问题，还是只能在后台解决？

一会回复你

你所说的重复处理，就是重传了。我以前跟手Q团队的人交流过，重传在主流IM里很正常，至于怎么重传，这就是算法策略问题了，各家实现基于种种考虑可能会略有不同。

MobileIMSDK里的重传策略：包括什么时候发回执、什么时候该重传、重传几次、多久重传一次等都是由客户端来决定的，服务端不涉及这些算法和策略，目的是减化算法并降低服务端负载（保持服务端简单性，就等于给未来的性能优化提供更多可能性）。但服务端唯一要做的就是将客户端决定的重传消息再次尝试投递给另一个客户端而已，因为现在的即时退讯文字消息都是通过服务端中转，这一关是省不了的。

好在重传并非常态，只是正常通讯时以非常小的几率发生而已，整体来说，对服务端的负载没有多大影响，即使有影响，从算法的角度来说也是可以优化的。

一个误解是UDP理论上可能丢包，但丢包几率并没有那么夸张，否则它就真没有存在的价值了（比如实时音视频聊天，大家都首选UDP，而且几乎不重传，如真如大家所想的丢包这么平常，那还能正常玩吗）。

引用：JackJiang 发表于 2016-06-24 09:50
你所说的重复处理，就是重传了。我以前跟手Q团队的人交流过，重传在主流IM里很正常，至于怎么重传，这就是 ...

你的意思，是不是说：
1、重传无法避免，即客户端收不到服务端回执的情况是存在的。所以会产生用户只发送一条消息，结果其他人收到2条的情况。
2、服务端不对重传的消息做过滤，仍然还是正常做投递。
3、通过优化客户端的重传策略，降低重传的概率

即时通讯里的算法都需要很精巧才行，不然大并发时性能会指数下降，这也是真正能用于生产的即时通讯为什么这么难搞的原因。

引用：kezhaoyuan 发表于 2016-06-24 09:56
你的意思，是不是说：
1、重传无法避免，即客户端收不到服务端回执的情况是存在的。所以会产生用户只发 ...

1）客户端收不到回执的可能性理论上也同样存在（你概率已经越来越小了），但对方收到重复消息在MobileIMSDK里绝不可能存在，因为算法层面已经做了处理。
2）服务端只管左手进右手出，算法由客户端完成，最大效率进行网络吞吐才是它最要作的事；
3）丢包概率没法优化，因为这是你的网络状况决定的，但重传的策略可以优化，这就是你算法要解决的事了。

引用：JackJiang 发表于 2016-06-24 10:01
1）客户端收不到回执的可能性理论上也同样存在（你概率已经越来越小了），但对方收到重复消息在MobileIMS ...

关于MobileIMSDK在接收方做的处理，我曾经在Q群见你提起过，大致思路就是：客户端做一个短队列，记录比如10条以内的消息，当收到新消息时，判断是否与这10条相同，如果相同就丢弃。
根据这一思路来，能否这样做：
客户端发送消息时，对消息生成UUID，然后一起发送给服务端。服务端对客户端生成的UUID不做处理，直接发送给接收方，接收方根据UUID来做过滤。
这样一来，消息体会不会太臃肿？

关于MobileIMSDK的QoS关达保证机制原理，我已在这个帖子里回过了：http://www.52im.net/thread-129-1-3.html

引用：JackJiang 发表于 2016-06-24 09:50
你所说的重复处理，就是重传了。我以前跟手Q团队的人交流过，重传在主流IM里很正常，至于怎么重传，这就是 ...

学习了

学习了，我现在也是遇到这个问题。但是如果是按照楼7方法处理出现消息重复的概率太高了。请问有没有解决的思路

引用：Liven 发表于 2017-10-31 15:58
学习了，我现在也是遇到这个问题。但是如果是按照楼7方法处理出现消息重复的概率太高了。请问有没有解决的 ...

去看下MobileIMSDK的实现源码，几乎没有重复的可能性。