[已回复] MobileIMSDK的C2C消息逻辑优化讨论

我觉得现在C2C（用户给用户发私聊消息）流程有待优化，不知道我说的对不对，可以一起讨论，理由如下：

现在用户1（U1）给用户2（U2）发送私聊消息的逻辑如下的逻辑如下：
1、U1发给服务器S
2、服务器S转发给U2
3、U2发应答包给服务器S
4、服务器S转发应答包给U1
其中1和2是消息本身发送流程，3和4是消息应答包发送流程。

问题：U2已经掉线，可能导致U1本身在网络良好的情况下会发送不成功。
我这里解释下为什么是可能发送成功也可能是发送不成功，下面先设定一些条件：
如果服务端“模感度类型”设置的是3*10+1（即session多久过期），即心跳是10秒一次，即客户端心跳丢包容忍度为3个包。
如果客户客户设置QoS设置的隔10秒重发一次，且用户U2是发送了心跳包后马上退出
发送成功的情况：
客户端至少要再重发3次（一共4次），在第4次时服务器才发现U2掉线，然后走离线消息，
这种情况用户U1发消息给U2要等30秒才提示发送成功。（这种情况就是服务器设置的session多久过期和客户端重发间隔、次数要保持一次）
发送不成功的情况：
如果重发少于3次，那么会提示用户U1发送失败，但此时U1的网络环境很了。


这种情况可能不多见，但如果出现了，对用户U1来说不管是发送成功或发送不成功，体验都是不好的。


所以我觉得可以优化如下逻辑（就是桥接的逻辑）：
1、U1发给服务器S
2、服务器S直接给U1应答包
3、服务器S消息转发给U2
4、U2发应答包给服务器S
这样U2掉线就是服务器QoS消息重发（之前是客户端QoS重发）及离线消息这块的逻辑了。


不知道我这样有没有问题，当时JackJiang是基于什么原因没这么做，可以一起讨论下。