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

你的设计，理论上可以这样做。但有一个前提，那就是你用的协议一定是TCP的，因为如果是UDP的话，MsgN被服务端送出，到底cl_B有没有被收到，其实服务端是不知道的，这UDP协议的先天特性，无法改变。

MobileIMSDK用的是UDP协议，用的是4步，而且不管是从算法还是逻辑是都非常简单易懂，比你的TCP这个流程多了一步，有兴趣的话可以去看看。

可不可以只要四步 客户端 A MSG:R 服务器收到后，服务器发送msg到cl_B,
cl_b ack 给 服务器， 服务器ack响应给 客户端A？？？？？？？？

引用：ym_im 发表于 2018-01-11 18:16
可不可以只要四步 客户端 A MSG:R 服务器收到后，服务器发送msg到cl_B,
cl_b ack 给 服务器， 服务器ack响 ...

可以，MobileIMSDK框架就是这么干的。

ios客户端发一条消息 怎么判断这条消息已经成功发送给服务端了  
- (int) sendCommonDataWithStrNSString *)dataContentWidthStr toUserIdNSString *)to_user_id withTypeuint)typeu;  这个方法返回的成功,只是表示消息发送成功了,还是说已经确认后台收到消息了

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

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

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

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

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

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

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

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

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

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

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

谢谢分享

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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