首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

XMPP协议之消息回执解决方案

苦恼中寻找方法 在开始做即时通信时就知道了消息回执这个概念,目的是解决通讯消息因为各种原因未送达对方而提供的一种保障机制。...于是也看到了别人的方案: 发送者发送消息给服务端 服务端接收到消息后发送回执给发送者 发送者确认收到则结束,如果未收到就重发 服务端将消息记录一下,并推送给接收者,等待接收者的回执 接收者接收消息并发回执给服务端...服务端接收回执删除掉消息回执记录,表示已经发送完毕 如果一定时间内没收到重新推送消息给客户端 接收者如果收到消息进行去重处理,如果不重复的执行第5-6步 这个流程基本就是完成了消息回执的功能,核心点就是在于发送者...基本的设计思路也有了: 客户端维护两个列表(发送回执队列和接收回执队列),用于保存发送/接收消息回执情况 服务端也维护一个列表,用于记录消息回执的接收与发送情况,服务端对列表进行超时检查,如果回执未发送的重发消息...柳暗花明 在看别人的总结时发现XMPP有扩展协议是支持消息回执功能的,就是XEP-0184.了解下来这个协议确实是一套消息回执的实现方法,但是呢。。

2.2K70

IM群聊消息的已读回执功能该怎么实现?

更有甚者,钉钉的群聊“强制已读回执”功能,甚至能够知道谁读了消息,谁没有读消息(老板的福音啊)。 那么群聊消息的收发流程、消息送达保证、已读回执机制,到底该怎么实现呢?这就是今天要讨论的话题。...2、IM开发干货系列文章 本文是系列文章中的第14篇,总目录如下: 《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递》 《如何保证...如您对聊天消息的投递和送达机制等尚无概念,可先读本系列文章的以下几篇,有助于您详细掌握这方面的内容: 《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递...上述流程,只能确保接收方收到消息,发送方仍然不知道哪些人在线阅读了消息,哪些人离线未阅读消息,并没有实现已读回执,那已读回执会对系统设计产生什么样的影响呢?...消息回执表:用来记录消息的已读回执 msg_acks(sender_uid, msgid, recv_uid, gid,if_ack); 各字段的含义为:发送方UID,消息ID,回执方UID,群ID,回执标记

4.9K20
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Akka(15): 持久化模式:AtLeastOnceDelivery-消息保证送达模式

    消息保证送达是指消息发送方保证在任何情况下都会至少一次确定的消息送达。...AtleastOnceDelivery是一个独立的trait,主要作用是对不确定已送达消息进行补发,这是一种自动的操作,无需用户干预。...所以AtleastOnceDelivery提供了自身特殊的事件(event)和快照(snapshot)类型,它们都包括消息送达状态。...confirmDelivery(deliveryId)用这个id来确认某条消息已经送达: /** * Call this method when a message has been confirmed...系统对超过配置文件中重发次数设置的消息通过自发送一条UnconformedWarning信息,这个信息包嵌了当前未确认送达消息清单: /** * @see [[AtLeastOnceDeliveryLike

    1.4K50

    消息已读回执(这个diao),究竟是推还是拉?

    有甚者,钉钉的群有“强制已读回执”功能,你在群里发出的消息,能够知道谁读了消息,谁没有读消息。...上述流程,只能确保接收方收到消息,发送方仍然不知道哪些人在线阅读了消息,哪些人离线未阅读消息,并没有实现已读回执,那已读回执会对系统设计产生什么样的影响呢?...二、已读回执流程 对于发送方发送的任何一条群消息,都需要知道,这条消息有多少人已读多少人未读,就需要一个基础表来记录这个关系。 消息回执表:用来记录消息的已读回执。...增加了已读回执逻辑后,群消息的流程会有细微的改变。 ? 步骤二,server收到消息后,除了要: 将群消息落地 查询群里有哪些群成员,以便实施推送 之外,还需要: 插入每条消息的初始回执状态 ?...答:回执数据不是核心数据 已读的消息,可以进行物理删除,而不是标记删除 超过N长时间的回执,归档或者删除掉 四、总结 对于群消息已读回执,一般来说: 如果发送方在线,会实时被推送已读回执 如果发送方不在线

    1.5K30

    IM消息送达保证机制实现(二):保证离线消息的可靠投递1、前言2、学习交流3、IM消息送达保证系列文章4、消息接收方不在线时的典型消息发送流程5、典型离线消息表的设计以及拉取离线消息的过程6、上述流

    1、前言 本文的上篇《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》中,我们讨论了在线实时消息的投递可以通过应用层的确认、发送方的超时重传、接收方的去重等手段来保证业务层面消息的不丢不重...(本文同步发布于:http://www.52im.net/thread-594-1-1.html) 2、学习交流 - 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》 3、IM消息送达保证系列文章...本文是讨论IM消息送达保证系列文章中的第2篇,总目录如下: 《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递》(本文)...4、消息接收方不在线时的典型消息发送流程 ?...如同在线消息的应用层ACK机制一样,离线消息拉时,不能够直接删除数据库中的离线消息,而必须等应用层的离线消息ACK(说明用户B真的收到离线消息了),才能删除数据库中的离线消息

    78521

    企业微信的IM架构设计揭秘:消息模型、万人群、已读回执消息撤回等

    例如:回执消息,发送方能看到已读未读列表,接受方只能看到是否已读的状态。云端删除某条群消息,在自己的消息列表消失,其他人还是可见。 缺点:存储容量的增加。...11、to B业务功能的设计与优化2:回执消息 11.1 技术背景 回执消息是办公场景经常用到的一个功能,能看到消息接受方的阅读状态。...一条回执消息的阅读状态会被频繁修改,群消息被修改的次数和群成员人数成正比。每天上亿条消息,读写频繁,请求量巨大,怎么保证每条消息在接受双方的状态是一致的是一个难点。...11.4 优化2:合并处理 客户端收到大量消息,并不是一条一条消息已读确认,而是多条消息一起已读确认。为了提高回执消息的处理效率,可以对多条消息合并处理。...回执消息分析过:通过referid指向,必须要知道原消息的msgid。 区别于回执消息:撤回消息需要修改所有接收方的消息状态,而不仅仅是发送方和单个接收方的。

    2.8K24

    环信WebIM 发送图片消息和显示图片 发送文件和显示文件 发送表情和显示表情

    ) { //收到音频消息 console.log(`已收到音频消息,消息内容为${JSON.stringify(message)}`) }, onLocationMessage: function...(message) {},//收到位置消息 onFileMessage: function (message) { //收到文件消息 console.log(`已收到文件消息,消息内容为...将好友从黑名单移除都会回调这个函数,list则是黑名单现有的所有好友信息 console.log(list) }, onReceivedMessage: function (message) {}, //收到消息送达服务器回执...onDeliveredMessage: function (message) {}, //收到消息送达客户端回执 onReadMessage: function (message) {},...//收到消息已读回执 onCreateGroup: function (message) {}, //创建群组成功回执(需调用createGroupNew) onMutedMessage

    1.4K10

    Android推送的群魔乱舞

    华为消息回执模式 与两者对应也有两种消息的概念:透传消息与通知栏消息: 透传消息:APP存活情况下,由推送服务直接把消息发送给APP应用,由APP自己选择如何处理,注意透传的前提是APP存活 ,透传消息可以不用接入第三方...image 对于在线透传消息,由于是在APP存活的情况下收到的,APP端可以统计到所有必要信息,无论是推送达时间、推送内容还是通知的点击都能统计到;但是离线推送就没那么幸运,很多信息APP自己是拿不到的...华为消息回执模式 可以看到,离线推送的情况下,华为设备在展示完通知栏消息后,会给华为Push服务一个回执,而华为Push服务会把这个回执头传给开发者服务器,如此,APP服务端就能判断推送是否到达。...推送送达率=本次推送真正送达的设备数/所覆盖的所有设备数(按理说,是应该清理掉无效设备) 哪些因素影响送达率 留存率。...消息有效期,基本所有第三方PUSH平台都支持设置有效期,有效期越短,触达设备就越少,送达率会下降,可以适当选择有效时间。

    1.8K20

    得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践

    1、引言本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题,从零到一构建完整的消息推送质量监控体系和机制的技术实践。...2、消息推送的作用2.1 什么是消息推送消息推送每天都在我们的手机上发生,如下图所示,除非你的手机没有安装App或关闭了通知栏权限。...对于消息推送而言,我们主要关注的是消息能否及时可靠的送达给用户,也就是SLA中关注的时效性和稳定性的问题。目前消息中心针对实效性和稳定性的开发已经完成并初显成效。...2)从现有数据来看,厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常,所以推送成功率、回执成功率、点击率的监控是必须的。...3)另外从业务请求发送的用户数来看,每天的消息推送基本是稳定的,相对应的厂商的回执数量和点击数量也是稳定的,那么对厂商推送成功的数量,回执的数量和点击的数量监控也有一定的参考意义。

    19610

    IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?

    1、前言 IM的群聊消息,究竟存1份(即扩散读方式)还是存多份(即扩散写方式)? 上一篇文章《IM群聊消息的已读回执功能该怎么实现?》...《IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议》 3、IM开发干货系列文章 本文是系列文章中的第15篇,总目录如下: 《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递...》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递》 《如何保证IM实时消息的“时序性”与“一致性”?》...《现代IM系统中聊天消息的同步和存储方案探讨》 《关于IM即时通讯群聊消息的乱序问题讨论》 《IM群聊消息的已读回执功能该怎么实现?》...(这里指的是作者的上篇文章《IM群聊消息的已读回执功能该怎么实现?》)

    1.6K20

    APP通知栏、微信、短信、邮箱消息推送:多渠道消息触达平台

    1.介绍 多渠道消息触达平台是一个为应用开发者提供服务的平台,旨在解决发送消息的需求。 通过与消息触达平台的接口对接,开发者无需自行编写发送消息的代码,从而实现业务逻辑代码和发送消息逻辑代码的解耦。...高性能消息推送:基于阻塞队列+消息队列+动态线程池处理消息任务,可处理大量消息任务 推送灵活:支持自定义消息内容实时、定时单个推送和批量推送 消息模板发送 数据可视化:对每个消息模板的推送情况进行可视化图形展示...Redis:使用Redis实现消息的链路追踪,对消息的各个阶段进行实时监控、日志记录和消息发送记录,掌控消息的生命周期。 Xxl-job:用于定时启动定时消息任务,实现消息的定时发送功能。...ECharts可视化:通过使用ECharts,对消息模板下发用户数、今日消息送达率、每天各时间段发送情况以及消息模板用户等数据进行可视化展示,方便进行消息模板的数据分析。...:支持手机号回执拉取    - 腾讯云:支持手机号回执拉取、账号回执拉取 APP通知栏 微信公众号    - 模板消息 钉钉群机器人    - 文本    - Markdown    - 链接消息

    86520

    从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

    这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制(因为我个人对移动客户端的经验积累的比较丰富嘛)。...github:https://github.com/music4kid 作者的博客:http://mrpeak.cn/About/ 3、相关文章 IM开发干货系列文章或许也值得您读一读,总目录如下: 《IM消息送达保证机制实现...(一):保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递》 《如何保证IM实时消息的“时序性”与“一致性”?》...移动端实时音视频开发的几个建议》 《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》 >> 更多同类文章 …… [8] IM开发综合文章: 《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制...《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》 《IM消息送达保证机制实现(二):保证离线消息的可靠投递》 《如何保证IM实时消息的“时序性”与“一致性”?》

    2.4K20

    IM开发干货分享:有赞移动端IM的组件化SDK架构设计实践

    1)IM会话首次请求数据流程: 2)IM下拉获取历史数据流程:  3)IM单条消息发送持久化方案: 4)IM单条数据重发流程:  10、设计不足之处 1)消息回执: 当前的设计方案中,没有消息回执的机制...一种可行的设计方式是,发送方增加已送到和未送达的状态,接收方收到消息后,给服务器返回已收到消息的通知,服务器再推送给发送方该状态,如果没有收到接收方回执,服务器可尝试重新推送。...发送方接受到接收方的收到回执后,更新发送状态已发送,如果未收到,则显示未送达。为了防止接收方回执丢失,接收方接收消息时候,可维护本地去重队列。...针对以上两点不足,感兴趣的读者,可以研究一下MobileIMSDK开源工程源码https://github.com/JackJiang2011/MobileIMSDK,MobileIMSDK已经实现了完整的消息送达保证机制...(包括:ACK回执、重传、去重、超时判定等等)。

    1.8K20

    推送 从入门到放弃的文案_百度推送自己不喜欢的内容

    在线下发率 在线消息下发数/总下发数。 回执消息回执数(去重)/消息在线下发数。 到达率 到达数/实际下发数。...到达数 客户端SDK接收到消息的设备数(通过统计客户端SDK接收到消息后的回执获得)。 展示数 用自定义非透传消息在用户手机展示过的设备数。 点击数 点击通知栏消息的设备数。...OK,推送发出去后,客户端收到推送消息,并产生回执,代表完成了一次推送,假设这些完成推送的设备是55w,这个就是送达设备数。...一般来说,只要设备在线,基本都能送达,所以这个数字和在线设备数非常接近,不接近的话,这个推送基本就有问题了,其中可能送不达的原因就在于网络切换等导致长连接断掉这类因素。...而一般的到达率,应该是送达设备数/可送达设备数,也就是百日内活跃的设备数,这样一除,这个比例一下子就小了很多,因为谁也不知道,这一百天内曾经活跃的用户,第二天是不是就已经把你卸载了。

    65110

    推送,从入门到放弃

    在线下发率 在线消息下发数/总下发数。 回执消息回执数(去重)/消息在线下发数。 到达率 到达数/实际下发数。...到达数 客户端SDK接收到消息的设备数(通过统计客户端SDK接收到消息后的回执获得)。 展示数 用自定义非透传消息在用户手机展示过的设备数。 点击数 点击通知栏消息的设备数。...OK,推送发出去后,客户端收到推送消息,并产生回执,代表完成了一次推送,假设这些完成推送的设备是55w,这个就是送达设备数。...一般来说,只要设备在线,基本都能送达,所以这个数字和在线设备数非常接近,不接近的话,这个推送基本就有问题了,其中可能送不达的原因就在于网络切换等导致长连接断掉这类因素。...而一般的到达率,应该是送达设备数/可送达设备数,也就是百日内活跃的设备数,这样一除,这个比例一下子就小了很多,因为谁也不知道,这一百天内曾经活跃的用户,第二天是不是就已经把你卸载了。

    1.9K20
    领券