请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 40
引用: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个报文会同时回调吗
WechatIMG11.png
引用: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,以此来判断消息是否需要离线存储.
签名: 从未放弃思考何时才能成为别人眼中的大神!
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部