引用：hujisha 发表于 2019-03-02 10:25
不是很理解，既然tcp已经提供了确认机制，为什么应用层还要再加一个呢？

你需要读一下这篇文章：《为什么说基于TCP的移动端IM仍然需要心跳保活？》

引用：110766457 发表于 2019-01-22 13:30
你好，我想说一下自己的看法。
我觉得重发应该放在服务端而不是客户端。如果重发逻辑在客户端，会有这样 ...

你说的第1种情况：如果此时B的网络确实差，对于服务端而言，就会判定对方离线，此时走离线消息逻辑就可以了，而A这边会收到服务端的伪应符包——对于A的体验是，消息还是送出了，只是不知道对方是不是实时收到了还是存入离线了而已；

第2种情况：确实存在这样的问题，但这是非常极端的情况下，而且一般的算法，在app挂起时，重传逻辑也挂起了，下次打开时还会重新开始。但，如果app被系统杀掉了就没招了。

但做法没有一个固定的套路，这也是im为什么不好写的原因，因为不标准，一百个人有一百个实现方法。能解决自已的问题就行了，不用太过纠结

不是很理解，既然tcp已经提供了确认机制，为什么应用层还要再加一个呢？

引用：JackJiang 发表于 2017-09-25 21:47
你的理解其实也是方案的一种，但一个现实情况是：
在高并发的场景下有些逻辑能放到客户端做的就尽量别放 ...

你好，我想说一下自己的看法。
我觉得重发应该放在服务端而不是客户端。如果重发逻辑在客户端，会有这样两个现象：
1.假如clientB网络不好（偏远山区2G网），那么由于clientB的原因导致clientA需要不断的重试，然而A给其他人发消息都没问题，唯独给B发消息发不过去。
2.很多人用IM(如微信）的时候有这样的习惯，发送一条消息后，就直接把微信切后台或关掉了，如果消息发送到server端成功，但发送到clientB失败了，由于clientA已经关闭，消息就不能重发了，这样也是不好的。

引用：cnbizsm 发表于 2018-05-28 16:07
感觉好像还是有问题的,如果服务端认为发送成功了,就不会离线缓存了吧,这样cl_B上线的时候就不能拉取丢失 ...

我也觉得有问题, 服务端和Client_B之间需要一个消息发送成功或失败的ack,以此来判断消息是否需要离线存储.

引用：cron_vQ07C 发表于 2018-12-03 14:12
我是服务端的，我刚在做的是一个推送系统。给所有在线的用户（app）推个消息，现在加入了重试机制。我想 ...

你如果是做推送系统，服务端可以单独起一个线程，检查未收到ack的包队列。

引用：JackJiang 发表于 2018-12-03 12:04
你这代码是客户端的还是服务端的？

我是服务端的，我刚在做的是一个推送系统。给所有在线的用户（app）推个消息，现在加入了重试机制。我想的是，用netty的定时任务（Schedule task with EventLoop），定时查等待ack队列。

引用：cron_vQ07C 发表于 2018-12-03 10:55
谢谢您的回复，我想再问下具体的。因为我用的就是netty，我关于每个连接用户，是启动这个定时任务的，
  ...

你这代码是客户端的还是服务端的？

引用：JackJiang 发表于 2018-11-30 19:25
ACK重传算法机制是在客户端实现的，所以这不难。
服务端的连接超时这些东西，如果你用java的netty或mina ...

谢谢您的回复，我想再问下具体的。因为我用的就是netty，我关于每个连接用户，是启动这个定时任务的，
            ctx.executor().schedule(() -> {
                //查当前连接的，等待ack队列
            },10,TimeUnit.SECONDS);
请问针对每个连接，都起这个，合适吗。

引用：cron 发表于 2018-11-30 15:25
您好，关于9，消息的超时与重传，有几个问题，想请教一下。维护的等待ack队列，是从接收方维度来分的吗。比 ...

ACK重传算法机制是在客户端实现的，所以这不难。
服务端的连接超时这些东西，如果你用java的netty或mina的话，它们都给你实现好了，不需要你自已这样野蛮地实现了

您好，关于9，消息的超时与重传，有几个问题，想请教一下。维护的等待ack队列，是从接收方维度来分的吗。比如现在同时连接1w用户，那他们都会有自己的等待ack队列吗。还有超时timer,也是针对每个连接的吗？每次连接上来，timer就启动吗？

引用：lmyJavaDE1 发表于 2018-09-03 13:49
请问 这张图的第二步的包如果丢了 客户端怎么判断丢了，是不是也是定时判断？
第六步的包丢了，客户端定 ...

你只要记住一个原则：只要发送方没有收到接收方的应答，它就可以认为消息没达送，不管中间有多少环节。

至于重传间隔，这是个经验值，你需要在你的IM用户能容忍多长的消息延迟（重传消息对于用户来说，就是延迟的消息）、和服务端的性能负载上来决定，比如3秒、5秒。。，时间如果太长的话，那就不叫即时通讯了，影响体验

引用：JackJiang 发表于 2018-06-14 10:20
其实1、2、3、4就够了，5和6可以省去。做im并不是做金融系统，没有必要也很难保证理论上的百分之百，qq和 ...

请问 这张图的第二步的包如果丢了 客户端怎么判断丢了，是不是也是定时判断？
第六步的包丢了，客户端定时重传的话，这个超时时间应该定在哪个范围好呢？

谢谢分享

引用：zgy5352 发表于 2018-06-13 21:10
如果对方在线,QOS 的6个报文,第2个报文和第6个报文会同时回调吗

其实1、2、3、4就够了，5和6可以省去。做im并不是做金融系统，没有必要也很难保证理论上的百分之百，qq和微信的设计原则同样遵循万有一失这个原则。

如果对方在线,QOS 的6个报文,第2个报文和第6个报文会同时回调吗

引用：x931609201 发表于 2017-11-17 11:11
我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A ...

感觉好像还是有问题的,如果服务端认为发送成功了,就不会离线缓存了吧,这样cl_B上线的时候就不能拉取丢失的消息了

引用：zgy5352 发表于 2018-05-23 17:37
如果对方在线确实会走 messagesBeReceived 这个回调,但是如果对方不在线,那个回调就不会走

不在线的话，服务端会走回离线处理 ServerEventListener. onTransBuffer_C2C_RealTimeSendFaild_CallBack()，你实现了服务端的离线处理后，服务端会代对方向你发送一个消息确认ACK，你就可以在iOS这里收到了，具体你看看onTransBuffer_C2C_RealTimeSendFaild_CallBack的文档说明（尤其是关于返回值的）。网络通信程序都是需要客户端和服务端配合成一个整体成实现的。

引用：JackJiang 发表于 2018-05-23 17:11
MobileIMSDK中，对方收到的消息，会通过MessageQoSEvent中的回调方法：- (void) messagesBeReceived: 告 ...

如果对方在线确实会走 messagesBeReceived 这个回调,但是如果对方不在线,那个回调就不会走

引用：zgy5352 发表于 2018-05-23 17:08
ios客户端发一条消息 怎么判断这条消息已经成功发送给服务端了  
- (int) sendCommonDataWithStrNSStrin ...

MobileIMSDK中，对方收到的消息，会通过MessageQoSEvent中的回调方法：- (void) messagesBeReceived: 告诉你。