CN105871703A - 推拉结合的即时通信消息获取系统和方法 - Google Patents
推拉结合的即时通信消息获取系统和方法 Download PDFInfo
- Publication number
- CN105871703A CN105871703A CN201610385811.7A CN201610385811A CN105871703A CN 105871703 A CN105871703 A CN 105871703A CN 201610385811 A CN201610385811 A CN 201610385811A CN 105871703 A CN105871703 A CN 105871703A
- Authority
- CN
- China
- Prior art keywords
- message
- client
- communication
- communication message
- instant
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/214—Monitoring or handling of messages using selective forwarding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/224—Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/234—Monitoring or handling of messages for tracking messages
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种推拉结合的即时通信消息获取系统和方法,其中,推拉结合的即时通信消息获取系统,包括,通讯消息版本号模块:给用户端分配通讯消息版本号;分布式缓存/存储模块:存储通讯消息发送队列和对应通讯消息版本号,获取用户端当前已分配的最大通讯消息版本号,并对通讯消息版本号进行递增操作;通讯消息推送模块:采用在线消息即时推送和定时消息集中补偿的方式给客户端发送消息;通讯消息拉取模块:当客户端接收到服务端推送的通知报文时,客户端向发起服务端发起请求,获取未到达的消息。实现将通讯消息安全、灵活、高效且可靠的推送给通讯客户端的优点。
Description
技术领域
本发明涉及通信领域,具体地,涉及一种推拉结合的即时通信消息获取系统和方法。
背景技术
随着互联网移动化智能化,互联网APP、移动APP、企业应用、网上商城,网络游戏等产品发展迅速,这些产品或多或少的会依赖即时通讯服务,一部分产品甚至以即时通讯服务为产品和功能的入口。目前,市场上存在很多即时通信的产品和服务,这些产品的质量也是参差不齐。对任何一个即时通讯的产品和服务,有以下的问题不可避免的需要重视和考虑:
通讯消息在传输中,由于网络问题,或者服务器故障,导致消息不能及时到达目标,有一定的延迟,甚至永久丢失。这种情况可能给用户带来了许多不便,甚至造成了一些资源浪费和财产损失。并且发生这种情况后,用户会对产品和服务出现不信任的态度,并很可能会考虑寻求类似的产品做替换。
而为了解决上一个问题,不同的公司和组织设计了各种方案,其中很多方案需要服务器和客户端做大量的编程和更改,甚至需要牺牲很大的效率,才能提高消息的一部分可靠性。
由于上一个问题中解决方案的复杂度,服务器和客户端的故障率都很可能增加,并且严重影响服务器的更新和扩展性,服务可用率不升反降。不良的解决方案反而会将产品带入一个恶性循环,为了解决消息不可靠的问题而提出的解决方案,反而导致了产品和服务更加的不可靠。
发明内容
本发明的目的在于,针对上述问题,提出一种推拉结合的即时通信消息获取系统和方法,以实现将通讯消息安全、灵活、高效且可靠的推送给通讯客户端的优点。
为实现上述目的,本发明采用的技术方案是:
一种推拉结合的即时通信消息获取系统,包括,通讯消息版本号模块、分布式缓存/存储模块、通讯消息推送模块和通讯消息拉取模块;
所述通讯消息版本号模块:给用户端分配通讯消息版本号;
所述分布式缓存/存储模块:存储通讯消息发送队列和对应通讯消息版本号,获取用户端当前已分配的最大通讯消息版本号,并对通讯消息版本号进行递增操作;
所述通讯消息推送模块:采用在线消息即时推送和定时消息集中补偿的方式给客户端发送消息;
所述通讯消息拉取模块:当客户端接收到服务端推送的通知报文时,客户端向发起服务端发起请求,获取未到达的消息。
优选的,所述通讯消息版本号模块分配的通讯消息版本号,为从0开始递增的长整形数字。
优选的,所述分布式缓存/存储模块,使用key-value数据库实现。
优选的,所述在线消息即时推送具体为:
两个在线的通讯客户端发送消息时,通讯服务端对通讯消息进行转发,并且通过消息回执和通讯消息版本号保证消息到达通讯客户端。
优选的,所述定时消息集中补偿具体为:
当一定时间内,在线的通讯客户端没有使用回执将通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至通讯客户端,通知通讯客户端主动拉取通讯消息,直到通讯客户端发送消息回执确认消息到达。
优选的,所述通讯消息拉取模块获取未到达的消息时,请求的方式采用HTTP或HTTPS方式,并启用压缩和缓存机制。
同时本发明技术方案还公开一种推拉结合的即时通信消息获取方法,包括,
步骤1、即时通信客户端A通过即时通信服务端发送消息给即时通信客户端B;
步骤2、即时通信服务端接收到来自即时通信客户端A的通信消息后,判断即时通信客户端A的权限和消息合法性,满足条件后,即时通信服务端发送消息到达回执给即时通信客户端A;
步骤3、即时通信服务端为该条发送给即时通信客户端B的消息分配通讯消息版本号,并将该条信息和通讯消息版本号缓存/存储;
步骤4、判断即时通信客户端B是否在线,如即时通信客户端B离线则结束;
步骤5、如即时通信客户端B在线,则推送通讯消息给即时通信客户端B;
步骤6、如果即时通信服务端接收到来自即时通信客户端B对该条消息的回执,将该条消息标记为已到达,结束;
步骤7、如果即时通信服务端没有接收到即时通信客户端B对该条信息的回执,则将该条消息进行定时消息集中补偿机制处理;
步骤8、当满足定时消息集中补偿机制的处理条件时,即时通信服务端将提醒即时通信客户端B有没有接收的消息,即时通信客户端B收到通知报文后将通过消息拉取的方式获取通讯消息。
优选的,所述定时消息集中补偿机制具体为:当一定时间内,在线的即时通讯客户端没有使用回执将即时通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至即时通讯客户端,通知即时通讯客户端主动拉取通讯消息,直到即时通讯客户端发送消息回执确认消息到达。
本发明的技术方案具有以下有益效果:
本发明以推拉结合的消息收取为基础,实现了在即时通讯过程中,消息传递的即时可靠。采用此方式,一方面即时通讯消息不会长时间延迟和丢失。另一方面,服务器效率不会有明显下降.与现有技术的区别之处主要为:
目前的很多即时通讯实现,为将消息周期重复的推送给客户端,一旦客户端下载失败,会再次进行重试,在客户端处于网络不稳定情况下,会大大的影响服务器吞吐量;
而本发明使用推拉结合的推送机制,消息在服务器端有积压时,服务器采用大量短小的通知消息替代实际的体积很大的消息, 将通知消息推送给客户端。
这种方式在简化服务器和客户端设计,减少故障率,且便于服务器更新和横向扩展有很明显的优势;并且该机制很好的平衡了服务器性能和消息的实时性, 在稍微降低服务器性能的情况下,能够达到秒级的消息延迟。
而而在客户端收到通知后,通过HTTP短连接方式获取。采用HTTP连接不需要服务器和客户端实现自己的报文响应回执,仅仅需要灵活设置重试策略。
下面通过附图和实施例,对本发明的技术方案做进一步的详细描述。
附图说明
图1为本发明实施例所述的推拉结合的即时通信消息获取系统的逻辑关系框图;
图2为本发明实施例所述的推拉结合的即时通信消息获取方法的流程图;
图3为本发明实施例所述的客户端与服务器交互过程流程图。
具体实施方式
以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。
一种推拉结合的即时通信消息获取系统,包括,通讯消息版本号模块、分布式缓存/存储模块、通讯消息推送模块和通讯消息拉取模块;
通讯消息版本号模块:给用户端分配通讯消息版本号;
分布式缓存/存储模块:存储通讯消息发送队列和对应通讯消息版本号,获取用户端当前已分配的最大通讯消息版本号,并对通讯消息版本号进行递增操作;
通讯消息推送模块:采用在线消息即时推送和定时消息集中补偿的方式给客户端发送消息;
通讯消息拉取模块:当客户端接收到服务端推送的通知报文时,客户端向发起服务端发起请求,获取未到达的消息。
优选的,通讯消息版本号模块分配的通讯消息版本号,为从0开始递增的长整形数字。
分布式缓存/存储模块,使用key-value数据库实现。
在线消息即时推送具体为:
两个在线的通讯客户端发送消息时,通讯服务端对通讯消息进行转发,并且通过消息回执和通讯消息版本号保证消息到达通讯客户端。
定时消息集中补偿具体为:
当一定时间内,在线的通讯客户端没有使用回执将通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至通讯客户端,通知通讯客户端主动拉取通讯消息,直到通讯客户端发送消息回执确认消息到达。
通讯消息拉取模块获取未到达的消息时,请求的方式采用HTTP或HTTPS方式,并启用压缩和缓存机制。
同时本发明技术方案还公开一种推拉结合的即时通信消息获取方法,包括,
步骤1、即时通信客户端A通过即时通信服务端发送消息给即时通信客户端B;
步骤2、即时通信服务端接收到来自即时通信客户端A的通信消息后,判断即时通信客户端A的权限和消息合法性,满足条件后,即时通信服务端发送消息到达回执给即时通信客户端A;
步骤3、即时通信服务端为该条发送给即时通信客户端B的消息分配通讯消息版本号,并将该条信息和通讯消息版本号缓存/存储;
步骤4、判断即时通信客户端B是否在线,如即时通信客户端B离线,则结束;
步骤5、如即时通信客户端B在线,则推送通讯消息给即时通信客户端B;
步骤6、如果即时通信服务端接收到来自即时通信客户端B对该条消息的回执,将该条消息标记为已到达,结束;
步骤7、如果即时通信服务端没有接收到即时通信客户端B对该条信息的回执,则将该条消息进行定时消息集中补偿机制处理;
步骤8、当满足定时消息集中补偿机制的处理条件时,即时通信服务端将提醒即时通信客户端B有没有接收的消息,即时通信客户端B收到通知报文后将通过消息拉取的方式获取通讯消息。
优选的,所述定时消息集中补偿机制具体为:当一定时间内,在线的即时通讯客户端没有使用回执将即时通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至即时通讯客户端,通知即时通讯客户端主动拉取通讯消息,直到即时通讯客户端发送消息回执确认消息到达。
推拉结合的即时通信消息获取方法。其特点是:
服务端使用推送方式推送即时消息。推送包括以下两种方式:
1、在线消息即时推送的方式。服务器除了推送外,使用回执保证消息到达。没有收到回执的报文都认为发送失败,要求客户端重新发送。使用这种简单的方式,可以高效的解决客户端网络不稳定情况下的报文丢失;
2、在线消息集中补偿的方式。服务器周期性检测客户端没有收取的消息数量,在用户可以接受的时间范围内,快速大量的发送体积短小的通知消息,通知客户端需要收取消息,客户端使用下述拉取的方式获取。
客户端使用拉取方式获取即时消息。即服务端使用推送方式中已经说明的补偿方式通知客户端,客户端收到通知后,采用HTTP短连接主动请求消息。
这种方式,有以下好处:
1、可以很大程度上的简化服务器推送消息失败后重试的处理逻辑;如果采用推送重试的方式,需要服务端和客户端进行多次回执,逻辑复杂繁琐,且客户端与服务器需要执行大量的周期任务。
2、在客户端不可达时,通过发送简单的通知消息,替代发送完整的消息报文,在客户端物理网络断开(服务端无法感知客户端离线)和消息挤压较多的情况下,既简化服务器处理逻辑,更可以节省数百倍甚至上千倍的服务器出口流量;
3、使用短连接可以一次性接收大量的离线消息,而不会对即时消息通道造成拥堵,这样其他消息仍可以正常的收发,完全不影响其他业务模块消息的实时性;
4、在这种模型下,短链接服务器的部署非常简单而可靠,并且可以很容易做到横向扩展,即简单的通过增加部署的方式支撑逐渐增多的用户。
本发明提出的基于推拉结合的消息收取系统主要包括四个模块:消息版本号模块、分布式存储/缓存模块、通讯消息推送模块和通讯消息拉取模块。此系统的逻辑关系图如如1所示:
(1)通讯消息版本号模块:
通讯消息版本号是实现推拉结合的消息接收机制的核心,通讯消息版本号以用户为单元分配。发送给用户的每条消息和该用户的一个版本号进行对应,版本号为从0开始递增的长整形数字。
(2)分布式缓存/存储模块:
分布式缓存/存储模块需要存储通讯消息发送队列和对应版本号;通过该模块,可以获取用户当前已分配的最大版本号,并通过对版本号进行递增操作。该模块可以使用比较成熟的key-value数据库实现,如redis,memcached。
(3)通讯消息推送模块:
通讯消息推送模块包括以下两个部分和功能:
在线消息即时推送。两个在线的通讯客户端发送消息时,通讯服务器需要对通讯消息进行转发,并且通过消息回执和消息版本号保证消息的到达。
定时消息集中补偿,当一定时间内,在线的通讯客户端没有使用回执将通讯服务器推送的消息报文标记为已到达,即时通讯服务端将定期发送通知消息,通知客户端主动拉取直到客户端发送消息回执确认消息到达。
如图2所示,消息推送的步骤描述如下:
1.即时通信客户端A通过即时通信服务器发送消息给即时通信客户端B;
2.即时通信服务端接收到来自A的通信消息后,判断权限和消息合法性,满足条件后,发送消息到达回执给客户端A;
3.即时通信服务端为该条发送给B的消息分配版本号,并将该条信息和版本号缓存/存储;
4.判断通信客户端B是否在线,离线则结束;
5.推送通讯消息给客户端B;
6.如果接收到来自客户端B的对该条消息的回执,将该条消息标记为已到达,该过程结束;
7.没有接收到客户端对该条信息的回执,则将该条消息进行消息补偿机制处理。
8.当满足需要处理的条件时,比如已经距发送消息间隔指定时间,将提醒客户端有没有接收的消息。客户端收到通知报文后将通过消息拉取的方式获取通讯消息。
(4)通讯消息拉取模块:
当客户端接收到服务端推送的通知报文时,客户端向发起服务端发起请求,获取未到达的消息,请求的方式一般采用HTTP(S)方式,并启用压缩和缓存机制,使得这种方式简单高效可靠。需要注意的是缓存机制针对特定的场景有效,并不适合所有场景。
在客户端通过服务器交互的过程中,存在以下具体的丢包或延迟情况,下面会说明详细的出现的场景以及本发明技术方案制如何解决场景中出现的问题:
1)客户端发往服务器丢包。当客户端发送消息后一定时间内没有接收到服务端回执,则客户端可以判定发送失败,客户端自定义处理即可,一般可以采用询问重发的策略。
2)服务器处理过程中宕机。服务器在将消息存储到高速的发送消息队列后(不需要等待发往目标客户端),再将回执发送给发送端。如果存储到发送队列前宕机,则客户端无法收到回执,认为发送失败,客户端重发;如果在存储到发送队列后宕机,由于服务器周期检测发送失败的消息,该消息会被通知给目标客户端收取。
3)服务端发往客户端丢包。这种情况由推送模块内的消息补偿机制保证可靠。服务端推送消息给客户端且一定时间内没有收到客户端回执,周期性发送体积很小的通知报文,通知客户端使用拉取方式获取,直到客户端成功获取消息或离线。该流程图3所示。
最后应说明的是:以上所述仅为本发明的优选实施例而已,并不用于限制本发明,尽管参照前述实施例对本发明进行了详细的说明,对于本领域的技术人员来说,其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (8)
1.一种推拉结合的即时通信消息获取系统,其特征在于,包括,通讯消息版本号模块、分布式缓存/存储模块、通讯消息推送模块和通讯消息拉取模块;
所述通讯消息版本号模块:给用户端分配通讯消息版本号;
所述分布式缓存/存储模块:存储通讯消息发送队列和对应通讯消息版本号,获取用户端当前已分配的最大通讯消息版本号,并对通讯消息版本号进行递增操作;
所述通讯消息推送模块:采用在线消息即时推送和定时消息集中补偿的方式给客户端发送消息;
所述通讯消息拉取模块:当客户端接收到服务端推送的通知报文时,客户端向发起服务端发起请求,获取未到达的消息。
2.根据权利要求1所述的推拉结合的即时通信消息获取系统,其特征在于,所述通讯消息版本号模块分配的通讯消息版本号,为从0开始递增的长整形数字。
3.根据权利要求1或2所述的推拉结合的即时通信消息获取系统,其特征在于,所述分布式缓存/存储模块,使用key-value数据库实现。
4.根据权利要求1或2所述的推拉结合的即时通信消息获取系统,其特征在于,所述在线消息即时推送具体为:
两个在线的通讯客户端发送消息时,通讯服务端对通讯消息进行转发,并且通过消息回执和通讯消息版本号保证消息到达通讯客户端。
5.根据权利要求4所述的推拉结合的即时通信消息获取系统,其特征在于,所述定时消息集中补偿具体为:
当一定时间内,在线的通讯客户端没有使用回执将通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至通讯客户端,通知通讯客户端主动拉取通讯消息,直到通讯客户端发送消息回执确认消息到达。
6.根据权利要求5所述的推拉结合的即时通信消息获取系统,其特征在于,所述通讯消息拉取模块获取未到达的消息时,请求的方式采用HTTP或HTTPS方式,并启用压缩和缓存机制。
7.一种推拉结合的即时通信消息获取方法,其特征在于,包括,
步骤1、即时通信客户端A通过即时通信服务端发送消息给即时通信客户端B;
步骤2、即时通信服务端接收到来自即时通信客户端A的通信消息后,判断即时通信客户端A的权限和消息合法性,满足条件后,即时通信服务端发送消息到达回执给即时通信客户端A;
步骤3、即时通信服务端为该条发送给即时通信客户端B的消息分配通讯消息版本号,并将该条信息和通讯消息版本号缓存/存储;
步骤4、判断即时通信客户端B是否在线,如即时通信客户端B离线则结束;
步骤5、如即时通信客户端B在线,则推送通讯消息给即时通信客户端B;
步骤6、如果即时通信服务端接收到来自即时通信客户端B对该条消息的回执,将该条消息标记为已到达,结束;
步骤7、如果即时通信服务端没有接收到即时通信客户端B对该条信息的回执,则将该条消息进行定时消息集中补偿机制处理;
步骤8、当满足定时消息集中补偿机制的处理条件时,即时通信服务端将提醒即时通信客户端B有没有接收的消息,即时通信客户端B收到通知报文后将通过消息拉取的方式获取通讯消息。
8.根据权利要求7所述的推拉结合的即时通信消息获取方法,其特征在于,所述定时消息集中补偿机制具体为:当一定时间内,在线的即时通讯客户端没有使用回执将即时通讯服务端推送的消息报文标记为已到达时,即时通讯服务端将定期发送通知消息至即时通讯客户端,通知即时通讯客户端主动拉取通讯消息,直到即时通讯客户端发送消息回执确认消息到达。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610385811.7A CN105871703A (zh) | 2016-06-03 | 2016-06-03 | 推拉结合的即时通信消息获取系统和方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610385811.7A CN105871703A (zh) | 2016-06-03 | 2016-06-03 | 推拉结合的即时通信消息获取系统和方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105871703A true CN105871703A (zh) | 2016-08-17 |
Family
ID=56676087
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610385811.7A Pending CN105871703A (zh) | 2016-06-03 | 2016-06-03 | 推拉结合的即时通信消息获取系统和方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105871703A (zh) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106357503A (zh) * | 2016-08-19 | 2017-01-25 | 百度在线网络技术(北京)有限公司 | 消息处理方法与即时通讯服务器 |
CN108449261A (zh) * | 2018-03-19 | 2018-08-24 | 腾讯科技(深圳)有限公司 | 消息提示方法、消息版本号处理方法、装置和存储介质 |
CN108512741A (zh) * | 2018-02-06 | 2018-09-07 | 北京云中融信网络科技有限公司 | 即时通讯方法、装置及系统 |
CN109067910A (zh) * | 2018-09-13 | 2018-12-21 | 乐蜜有限公司 | 一种消息拉取的方法及装置 |
CN110311853A (zh) * | 2019-05-09 | 2019-10-08 | 重庆八戒电子商务有限公司 | 一种基于微信公众号实现消息触达的方法及、装置、计算设备以及存储介质实现消息触达 |
CN111083037A (zh) * | 2019-10-22 | 2020-04-28 | 贝壳技术有限公司 | 用于实现即时通讯的方法、装置、介质以及电子设备 |
CN111211973A (zh) * | 2020-01-15 | 2020-05-29 | 百望股份有限公司 | 发票领域的消息处理方法、装置及存储介质 |
CN112398726A (zh) * | 2020-11-05 | 2021-02-23 | 深圳市和讯华谷信息技术有限公司 | 推送消息的回执信息处理方法、系统及存储介质 |
CN112448883A (zh) * | 2020-10-14 | 2021-03-05 | 苏宁云计算有限公司 | 消息推送方法、装置、计算机设备和存储介质 |
CN112583701A (zh) * | 2020-12-16 | 2021-03-30 | 焦点科技股份有限公司 | 一种基于版本号的高可靠消息机制来保证消息的方法 |
CN113079382A (zh) * | 2021-03-24 | 2021-07-06 | 百度国际科技(深圳)有限公司 | 消息传输方法、装置、设备、系统和存储介质 |
CN113094002A (zh) * | 2021-05-12 | 2021-07-09 | 北京字节跳动网络技术有限公司 | 消息处理方法、装置、电子设备和计算机介质 |
CN113973097A (zh) * | 2020-07-24 | 2022-01-25 | 腾讯科技(深圳)有限公司 | 一种消息显示方法、装置和存储介质 |
CN115378894A (zh) * | 2022-08-26 | 2022-11-22 | 成都卫士通信息产业股份有限公司 | 一种消息同步方法、装置、设备及介质 |
CN115412519A (zh) * | 2022-08-29 | 2022-11-29 | 中国建设银行股份有限公司 | 消息传输方法、装置、服务器及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104023321A (zh) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | 基于移动网络的安全可靠的消息传输系统 |
CN104796871A (zh) * | 2015-04-30 | 2015-07-22 | 努比亚技术有限公司 | 即时消息业务的处理方法、装置及系统 |
CN105119816A (zh) * | 2015-09-16 | 2015-12-02 | 北京梅泰诺通信技术股份有限公司 | 消息发送状态的处理方法及装置 |
-
2016
- 2016-06-03 CN CN201610385811.7A patent/CN105871703A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104023321A (zh) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | 基于移动网络的安全可靠的消息传输系统 |
CN104796871A (zh) * | 2015-04-30 | 2015-07-22 | 努比亚技术有限公司 | 即时消息业务的处理方法、装置及系统 |
CN105119816A (zh) * | 2015-09-16 | 2015-12-02 | 北京梅泰诺通信技术股份有限公司 | 消息发送状态的处理方法及装置 |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106357503B (zh) * | 2016-08-19 | 2019-09-20 | 百度在线网络技术(北京)有限公司 | 消息处理方法与即时通讯服务器 |
CN106357503A (zh) * | 2016-08-19 | 2017-01-25 | 百度在线网络技术(北京)有限公司 | 消息处理方法与即时通讯服务器 |
CN108512741A (zh) * | 2018-02-06 | 2018-09-07 | 北京云中融信网络科技有限公司 | 即时通讯方法、装置及系统 |
CN108449261B (zh) * | 2018-03-19 | 2020-10-02 | 腾讯科技(深圳)有限公司 | 消息提示方法、消息版本号处理方法、装置和存储介质 |
CN108449261A (zh) * | 2018-03-19 | 2018-08-24 | 腾讯科技(深圳)有限公司 | 消息提示方法、消息版本号处理方法、装置和存储介质 |
CN109067910A (zh) * | 2018-09-13 | 2018-12-21 | 乐蜜有限公司 | 一种消息拉取的方法及装置 |
CN110311853A (zh) * | 2019-05-09 | 2019-10-08 | 重庆八戒电子商务有限公司 | 一种基于微信公众号实现消息触达的方法及、装置、计算设备以及存储介质实现消息触达 |
CN111083037B (zh) * | 2019-10-22 | 2022-02-01 | 贝壳技术有限公司 | 用于实现即时通讯的方法、装置、介质以及电子设备 |
CN111083037A (zh) * | 2019-10-22 | 2020-04-28 | 贝壳技术有限公司 | 用于实现即时通讯的方法、装置、介质以及电子设备 |
CN111211973A (zh) * | 2020-01-15 | 2020-05-29 | 百望股份有限公司 | 发票领域的消息处理方法、装置及存储介质 |
CN111211973B (zh) * | 2020-01-15 | 2022-06-21 | 百望股份有限公司 | 发票领域的消息处理方法、装置及存储介质 |
CN113973097A (zh) * | 2020-07-24 | 2022-01-25 | 腾讯科技(深圳)有限公司 | 一种消息显示方法、装置和存储介质 |
CN112448883A (zh) * | 2020-10-14 | 2021-03-05 | 苏宁云计算有限公司 | 消息推送方法、装置、计算机设备和存储介质 |
CN112398726A (zh) * | 2020-11-05 | 2021-02-23 | 深圳市和讯华谷信息技术有限公司 | 推送消息的回执信息处理方法、系统及存储介质 |
CN112583701A (zh) * | 2020-12-16 | 2021-03-30 | 焦点科技股份有限公司 | 一种基于版本号的高可靠消息机制来保证消息的方法 |
CN113079382A (zh) * | 2021-03-24 | 2021-07-06 | 百度国际科技(深圳)有限公司 | 消息传输方法、装置、设备、系统和存储介质 |
CN113094002A (zh) * | 2021-05-12 | 2021-07-09 | 北京字节跳动网络技术有限公司 | 消息处理方法、装置、电子设备和计算机介质 |
CN113094002B (zh) * | 2021-05-12 | 2023-07-18 | 抖音视界有限公司 | 消息处理方法、装置、电子设备和计算机介质 |
CN115378894A (zh) * | 2022-08-26 | 2022-11-22 | 成都卫士通信息产业股份有限公司 | 一种消息同步方法、装置、设备及介质 |
CN115412519A (zh) * | 2022-08-29 | 2022-11-29 | 中国建设银行股份有限公司 | 消息传输方法、装置、服务器及存储介质 |
CN115412519B (zh) * | 2022-08-29 | 2024-05-03 | 中国建设银行股份有限公司 | 消息传输方法、装置、服务器及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105871703A (zh) | 推拉结合的即时通信消息获取系统和方法 | |
US7813745B2 (en) | Method for implementing a push service | |
CN1960516B (zh) | 终端中完全一样的通知消息的处理方法 | |
CN103220206B (zh) | 一种消息发送方法、装置和一种消息接收方法、装置 | |
CN102143444B (zh) | 一种业务分发平台消息推送方法、相关设备及系统 | |
CN101997661B (zh) | 数据包发送方法、数据包获取方法及装置 | |
EP3437263B1 (fr) | Procédé de notification de l'indisponibilité d'un terminal | |
CN104811459A (zh) | 用于消息服务的处理方法、装置及系统、消息服务系统 | |
CN101160875A (zh) | 一种离线消息发送方法 | |
WO2007056928A1 (fr) | Procede et systeme d'adaptation pour terminal de messagerie mobile | |
CN108683653A (zh) | 一种基于WebSocket的主动式消息推送系统 | |
CN105490773B (zh) | 传输多媒体数据的方法和装置 | |
WO2011147144A1 (zh) | 短信复活系统、装置及方法 | |
WO2006058544A1 (en) | Method for delivering multimedia files | |
CN101888602A (zh) | 消息处理装置、方法、消息业务系统和消息中心 | |
CN105978796A (zh) | 基于不稳定移动网络的消息通信方法及系统 | |
WO2013166899A1 (zh) | 一种短消息传输的方法、装置及系统 | |
CN101150757B (zh) | 一种多媒体消息内容适配的方法和系统 | |
EP2690833B1 (en) | Media message sending method, device and system | |
WO2008037117A1 (fr) | Système destiné au traitement d'une tâche de programmation d'un message multimédia et procédé de mise en oeuvre associé | |
WO2010009666A1 (zh) | 多媒体业务的实现方法、系统和装置 | |
JP2011517796A (ja) | マルチメディアメッセージ保存アドレス送信システム及び方法 | |
CN106487890A (zh) | 一种基于xmpp协议的跨节点通讯网络请求方法 | |
CN104426746A (zh) | 客户端消息的推送方法、装置和服务器 | |
CN113489786A (zh) | 一种长连接网络弱网重连方法、重发方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20160817 |
|
RJ01 | Rejection of invention patent application after publication |