CN115412519A - 消息传输方法、装置、服务器及存储介质 - Google Patents
消息传输方法、装置、服务器及存储介质 Download PDFInfo
- Publication number
- CN115412519A CN115412519A CN202211041837.1A CN202211041837A CN115412519A CN 115412519 A CN115412519 A CN 115412519A CN 202211041837 A CN202211041837 A CN 202211041837A CN 115412519 A CN115412519 A CN 115412519A
- Authority
- CN
- China
- Prior art keywords
- message
- version number
- client
- sent
- receiver client
- 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.)
- Granted
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 67
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000012790 confirmation Methods 0.000 claims abstract description 117
- 238000012423 maintenance Methods 0.000 claims description 38
- 230000002159 abnormal effect Effects 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 10
- 230000001174 ascending effect Effects 0.000 claims description 7
- 238000004891 communication Methods 0.000 abstract description 10
- 238000010586 diagram Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 238000013461 design Methods 0.000 description 6
- 230000006978 adaptation Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 210000004243 sweat Anatomy 0.000 description 1
Images
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/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/18—Commands or executable codes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请提供一种消息传输方法、装置、服务器及存储介质。涉及通信技术领域。该方法包括:接收发送方客户端发送的携带接收方标识各消息报文;根据接收方标识和当前日期信息,为消息报文添加版本号;按照接收方标识,将添加版本号的消息报文发送至接收方客户端,并将添加至消息发送确认列表;若接收到接收方客户端发送的确认回复信息、且其中携带的版本号与消息发送确认列表中的消息报文的版本号相同,则将消息发送确认列表中对应的消息报文删除;若没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将消息发送确认列表中对应的消息报文重新发送。该方法在通信网不稳定等情况下能够保证消息报文传输成功。
Description
技术领域
本申请涉通信技术领域,尤其涉及一种消息传输方法、装置、服务器及存储介质。
背景技术
即时通信,是指基于服务端的消息传输服务,实现客户端与客户端之间的消息即时传输。
现有技术中,任一客户端将消息报文通过通信网络发送至服务端,服务端根据消息报文中携带的地址,再通过通信网络发送至对应的其他的客户端。
然而,发明人发现现有技术中至少存在如下技术问题:在通信网不稳定或客户端运行环境复杂等情况下,容易导致消息报文传输失败。
发明内容
本申请提供一种消息传输方法、装置、服务器及存储介质,用以解决现有技术中在通信网不稳定或客户端运行环境复杂等情况下,容易导致消息报文传输失败的问题。
第一方面,本申请提供一种消息传输方法,应用于服务端,包括:
接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识;
根据所述接收方标识和当前日期信息,将所述消息报文进行分组;
针对分组内的各消息报文,为消息报文添加版本号;其中所述版本号为按照接收消息报文的顺序由先到后以自然数递增排列;
按照所述接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将所述添加版本号的消息报文添加至消息发送确认列表;
若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除;
若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送。
在一种可能的设计中,所述服务端中存储有维护表,维护表用于记录接收方客户端已经接收到最新的消息报文的版本号,记为最新版本号;
所述若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除之后,还包括:
若所述确认回复信息中携带的版本号大于已接收版本号,则将所述维护表中的最新版本号更新为所述确认回复信息中携带的版本号;
相应地,所述若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送之后,还包括:
若将所述消息发送确认列表中对应的消息报文重新发送预设次数失败或所述消息发送确认列表中的消息报文数量超过预设数量时,则确定所述接收方客户端状态异常,并以所述消息发送确认列表中的最小版本号更新所述维护表中的最新版本号并清空所述消息发送确认列表;
在确定所述接收方客户端异常状态结束后,则通过查询服务端的数据库,按照所述维护表中的最新版本号开始按版本号递增的顺序发送各消息报文。
在一种可能的设计中,若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送之后,还包括:
将所述消息发送确认列表中对应的消息报文重新发送至所述接收方客户端,以使所述接收方客户端根据所述消息报文与历史消息报文的报文数据特征值进行比对,若存在相同的报文数据特征值,则确定所述消息报文为重复发送的报文,接收方客户端不显示所述消息报文。
在一种可能的设计中,所述消息传输方法还包括:
在确定任一接收方客户端离线后重新登录时,获取所述接收方客户端通过查询历史消息报文得到最新消息报文的版本号和日期信息;
根据所述最新消息报文的版本号和日期信息,通过查询服务端的数据库获取日期信息相同、版本号大于最新消息报文的版本号的消息报文,以及日期信息大于所述最新消息报文的日期信息的消息报文;
将查询得到消息报文发送至所述接收方客户端。
在一种可能的设计中,所述消息传输方法还包括:在确定任一接收方客户端离线后重新登录时,获取所述维护表中的最新版本号;
通过查询服务端的数据库,以维护表中的最新版本号开始按版本号递增的顺序获取相应的消息报文,并发送至接收方客户端。
在一种可能的设计中,所述消息传输方法还包括:在确定任一接收方客户端为首次登录时,通过查询服务端的数据库,获取以最大版本号开始由大到小的预设条数的消息报文,并发送至接收方客户端。
在一种可能的设计中,所述消息传输方法还包括:接收任一接收方客户端发送的消息查询请求,其中所述消息查询请求携带日期信息和版本号;
根据所述日期信息和版本号查询服务端的数据库,获取对应的历史消息报文,并将所述历史消息报文返回给接收方客户端。
第二方面,本申请提供一种消息传输装置,包括:
接收模块,用于接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识;
分组模块,用于根据所述接收方标识和当前日期信息,将所述消息报文进行分组;
添加模块,用于针对分组内的各消息报文,为消息报文添加版本号;其中所述版本号为按照接收消息报文的顺序由先到后以自然数递增排列;
发送模块,用于按照所述接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将所述添加版本号的消息报文添加至消息发送确认列表;
删除模块,用于若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除;
重新发送模块,用于若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送。
第三方面,本申请提供一种服务器,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现如第一方面所述的方法。
第四方面,本申请提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。
第五方面,本申请提供一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现第一方面所述的方法。
本申请提供的消息传输方法、装置、服务器及存储介质,通过为消息报文添加版本号,并通过在预设时长内是否接收到接收方客户端发送的确认回复信息、确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同来确定将消息发送确认列表中对应的消息报文删除或重新发送,可以最大程度地规避网络不稳性、客户端环境复杂导致消息报文传输失败的情况,提高网络可靠性,提升消息报文传送效率,增加终端用户体验。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1为适用于本申请实施例的消息传输方法的应用场景图;
图2为本申请实施例提供的消息传输方法的流程图一;
图3为本申请实施例中为消息报文添加版本号的方法;
图4为本申请实施例提供的消息传输方法的流程图二;
图5为本申请实施例提供的消息传输方法原理示意图;
图6为本申请实施例提供的消息传输装置的结构示意图;
图7为本申请实施例提供的服务器的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在当下,实时消息的应用范围逐步扩大,并且实时消息涉及重要业务消息的场景下,即时通信消息传输的可靠性越加重要。现有技术中,任一客户端将消息报文通过通信网络发送至服务端,服务端根据消息报文中携带的地址,再通过通信网络发送至对应的其他的客户端。在实际的即时通信业务场景中,由于存在各级网络扰动、客户端安全策略变动、终端移动设备移动互联网的弱网性,偶尔会出现因为服务端、客户端处理不当导致消息报文未重传、消息丢失、消息重传有效性低等消息报文传输失败的情况。
针对上述技术问题,本申请提出如下技术构思:为消息报文添加版本号,并通过在预设时长内是否接收到接收方客户端发送的确认回复信息、确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同来确定将消息发送确认列表中对应的消息报文删除或重新发送,最大程度地规避网络不稳性、客户端环境复杂导致消息报文传输失败的情况,提升消息报文传送效率。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本申请的实施例进行描述。
图1为适用于本申请实施例的消息传输方法的应用场景图。如图1所示,该应用场景包括:服务端101,客户端A102和客户端B103。其中,客户端B103为发送方客户端并进行消息发送,发送出的消息传输到服务端101,服务端101再将消息传输到客户端A102,客户端A102为接收方客户端并进行消息接收,完成从客户端B103至客户端A102的消息传输。
基于图1所示的应用场景,本申请实施例还提供一种消息传输方法。图2为本申请实施例提供的消息传输方法的流程图一,本实施例的方法的执行主体可以是图2中所示的服务端101。如图2所示,该消息传输方法包括:
S201、接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识。
本实施例中,消息报文指网络中交换与传输的数据单元,即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息,其长短很不一致,长度不限且可变。
接收方标识为接收方唯一身份,例如接收方标识的编制规则为:行政区划代码+类型+编号。
S202、根据接收方标识和当前日期信息,将消息报文进行分组。
本实施例中,将接收方标识相同且当前日期信息相同的消息报文分到一个组内。
S203、针对分组内的各消息报文,为消息报文添加版本号;其中版本号为按照接收消息报文的顺序由先到后以自然数递增排列。
本实施例中为消息报文添加版本号的逻辑流程,如图3所示,服务端记录了发送给接收方客户端A消息报文的版本号为N。
发送方客户端B向客户端A发送消息1,消息报文版本号记录为N+1。之后发送方客户端C向客户端A发送消息1.1消息报文版本号记录为N+2。之后发送方客户端B向客户端A发送消息2,消息报文版本号记录为N+3。之后发送方客户端C向客户端A发送消息1.2,此时消息报文版本号记录为N+4。
S204、按照接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将添加版本号的消息报文添加至消息发送确认列表。
本实施例中,消息发送确认列表中包括版本号以及版本号对应的消息报文,如表1所示:
表1:消息发送确认列表
S205、若在预设时长内接收到接收方客户端发送的确认回复信息、且确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同,则将消息发送确认列表中对应的消息报文删除。
本实施例中,预设时长根据消息推送频率、服务端服务资源等进行动态配置,对此本申请实施例不作任何限制,预设时长可以设定为5秒。若在5秒内接收方客户端接收到消息报文1、消息报文3和消息报文99后给出了消息接收确认回复,且确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同,则将消息发送确认列表中的消息报文1、消息报文3和消息报文99删除,删除后的消息发送确认列表如表2所示:
表2:消息发送确认列表
版本号N+2 | 消息报文2 |
版本号N+4 | 消息报文4 |
…… | …… |
…… | …… |
…… | …… |
…… | …… |
…… | …… |
…… | …… |
S206、若在预设时长内没有接收到接收方客户端发送的携带添加版本号的消息报文的版本号的确认回复信息,则将消息发送确认列表中对应的消息报文重新发送。
示例性地,本申请表2中的消息报文2和消息报文4在5秒内没有接收到接收方客户端发送的携带添加版本号的消息报文的版本号的确认回复信,则将消息报文2和消息报文4重新发送给接收方客户端。
综上,本实施例提供的消息传输方法,通过为消息报文添加版本号,并通过在预设时长内是否接收到接收方客户端发送的确认回复信息、确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同来确定将消息发送确认列表中对应的消息报文删除或重新发送,可以最大程度地规避网络不稳性、客户端环境复杂导致消息报文传输失败的情况,提高网络可靠性,提升消息报文传送效率,增加终端用户体验。
本申请中,图1所示的应用场景中,服务端中存储有维护表,维护表用于记录接收方客户端已经接收到最新的消息报文的版本号,记为最新版本号。图4为本申请实施例提供的消息传输方法的流程图二,在图2实施例的基础上,S205之后,还包括:
S207:若确认回复信息中携带的版本号大于已接收版本号,则将维护表中的最新版本号更新为确认回复信息中携带的版本号。
本实施例中,若已接收消息报文的版本号为N+1,确认回复信息中携带的版本号为N+99,那么就将维护表中的最新版本号更新为N+99;但是若已接收消息报文的版本号为N+99,确认回复信息中携带的版本号为N+3,则不对维护表中的最新版本号进行更新。
S206之后,还包括:
S208:若将消息发送确认列表中对应的消息报文重新发送预设次数失败或消息发送确认列表中的消息报文数量超过预设数量时,则确定接收方客户端状态异常,并以消息发送确认列表中的最小版本号更新维护表中的最新版本号并清空消息发送确认列表;
本实施例中,消息报文重新发送预设次数可以根据消息推送频率、服务端服务资源等进行动态配置,对此本申请实施例不作任何限制。例如,重新发送预设次数为3次或5次。
消息发送确认列表中的消息报文数量的预设数量可以根据消息推送频率、服务端服务资源等进行动态配置,对此本申请实施例不作任何限制。例如,预设数量为100或120。
S209:在确定接收方客户端异常状态结束后,则通过查询服务端的数据库,按照维护表中的最新版本号开始按版本号递增的顺序发送各消息报文。
本实施例中,服务端的数据库用于存储客户端消息,存储的客户端消息可以用于离线消息查询和历史消息查询。
示例性地,服务端的数据库中存储的客户端消息如表3所示:
表3:
Msg_id | 消息ID | char(20) |
To | 消息接收者ID | VARchar(68) |
From | 消息发送者ID | VARchar(68) |
Msg | 消息内容 | VARchar(2000) |
Rev_date | 服务器消息接收时间 | DATE |
Msg_ver | 消息版本号 | INTEGER |
需要说明的是,服务端的数据库中存储的客户端消息并不限于表3中包含的内容。
综上,本实施例提供的消息传输方法,针对网络异常的场景,服务器端维护有接收方客户端已经接收到最新的消息报文的版本号;当网络异常时,记录消息发送确认列表中的最小版本号,作为维护的最新版本号;在网络恢复时,重新发送,进一步保证消息报文的发送不会被遗漏。
在图2实施例的基础上,S206之后,还包括:
S210:将消息发送确认列表中对应的消息报文重新发送至接收方客户端,以使接收方客户端根据消息报文与历史消息报文的报文数据特征值进行比对,若存在相同的报文数据特征值,则确定消息报文为重复发送的报文,接收方客户端不显示消息报文。
本实施例中,报文数据特征值作为消息报文唯一识别标识,标识一致的消息报文则为相同消报文息。
综上,本实施例提供的消息传输方法针对接收方客户端实质上接收到了消息,但是由于网略异常,服务端没有接收到确认回复消息的情况,又将消息报文进行了重发的情况,对重复发送的消息报文进行消息去重,避免将消息报文重复发送给接收方客户端。
本申请的图2实施例和图4实施例中的消息传输方法存在多种特定的应用场景,例如:接收方客户端离线后重新登录,接收方客户端离线后重新登录且接收方客户端本地的数据库损坏,接收方客户端首次登录,接收方客户端擦汗寻历史消息。针对以上不同的特定的应用场景,本申请图2实施例和图4实施例中的消息传输方法还包括不同的消息传输方式。
本申请的一个实施例中,当接收方客户端为离线后重新登录时,
在确定任一接收方客户端离线后重新登录时,获取接收方客户端通过查询历史消息报文得到最新消息报文的版本号和日期信息;根据最新消息报文的版本号和日期信息,通过查询服务端的数据库获取日期信息相同、版本号大于最新消息报文的版本号的消息报文,以及日期信息大于最新消息报文的日期信息的消息报文;将查询得到消息报文发送至接收方客户端。
本实施例中,服务端的数据库与步骤S209中的服务端的数据库相同。
本申请的一个实施例中,当接收方客户端为离线后重新登录,且接收方客户端本地的数据库损坏时,在确定任一接收方客户端离线后重新登录时,获取维护表中的最新版本号;
通过查询服务端的数据库,以维护表中的最新版本号开始按版本号递增的顺序获取相应的消息报文,并发送至接收方客户端。
本实施例中,接收方客户端本地的数据库损坏例如由以下原因导致:重新安装、移除设备应用数据清理等。
本申请的一个实施例中,当接收方客户端首次登录时,
在确定任一接收方客户端为首次登录时,通过查询服务端的数据库,获取以最大版本号开始由大到小的预设条数的消息报文,并发送至接收方客户端。
本实施例中,若接收方客户端为首次登录,则下发最近N条离线消息。下发离线消息的条数N根据消息推送频率、服务端服务资源等进行动态配置,对此本申请实施例不作任何限制,N可以设定为100。
本申请的一个实施例中,当接收方客户端查询历史消息时,
接收任一接收方客户端发送的消息查询请求,其中消息查询请求携带日期信息和版本号;
根据日期信息和版本号查询服务端的数据库,获取对应的历史消息报文,并将历史消息报文返回给接收方客户端。
本实施例中,服务端的数据库与步骤S209中的服务端的数据库相同。
图5为本申请实施例提供的消息传输方法原理示意图,如图5所示,服务端中存储有维护表,维护表用于记录客户端A已经接收到最新的消息报文的版本号,记为最新版本号。
本实施例的消息传输方法包括以下步骤:
S501:客户端A接收不同发送方客户端发送的消息报文1、消息报文2、消息报文3、消息报文4……消息报文99,其中每条消息报文中携带接收方标识。
S502:根据客户端A标识和当前日期信息,将消息报文1至消息报文99进行分组,该实施例中消息报文1至99在同一组。
S503:针对分组内的消息报文1至99,为消息报文1至99添加版本号,其中消息报文1的版本号为N+1,消息报文2的版本号为N+2,以此类推,消息报文99的版本号为N+99。
S504:将消息报文1发送至客户端A,并将添加版本号N+1的消息报文1添加至消息发送确认列表。将消息报文2发送至客户端A,并将添加版本号N+2的消息报文2添加至消息发送确认列表。以此类推,将消息报文99发送至客户端A,并将添加版本号N+99的消息报文2添加至消息发送确认列表。
本实施例中消息发送确认列表的长度P为100。
S505:消息报文1、消息报文99和消息报文3依次在预设时长5秒内接收到客户端A发送的消息报文1确认回复信息、消息报文99确认回复信息和消息报文3确认回复信息,然后将消息发送确认列表中的消息报文1、消息报文99和消息报文3删除。
在此过程中,维护表内的最新版本号的更新过程如下:服务端接收到客户端A发出的消息报文1消息接收确认回复,维护表记录最新版本号为消息报文1的版本号N+1。然后服务端接收到客户端A发出的消息报文99消息接收确认回复,维护表记录最新版本号为消息报文99的版本号N+99。然后服务端接收到客户端A发出的消息报文3消息接收确认回复,但是消息报文3的版本号N+3小于之前维护表中的最新版本号N+99,所以维护表的最新版本号仍为N+99。
S506:消息报文2和消息报文4在预设时长5秒内没有接收到客户端A发送的消息报文2确认回复信息和消息报文4确认回复信息,则将消息发送确认列表中的消息报文2和消息报文4重新发送。
综上,本实施例提供的消息传输方法中为各消息报文添加版本号,并通过在预设时长内是否接收到接收方客户端发送的确认回复信息、确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同来确定将消息发送确认列表中对应的消息报文删除或重新发送。并且添加维护表,服务器端维护有接收方客户端已经接收到最新的消息报文的版本号。当网络异常时,记录消息发送确认列表中的最小版本号,作为维护的最新版本号;在网络恢复时,重新发送,进一步保证消息不会被遗漏。本实施例的方法最大程度地规避网络不稳性、客户端环境复杂导致消息报文传输失败的情况,提高了网络可靠性,提升了消息报文传送效率,增加了终端用户体验。
图6为本申请实施例提供的消息传输装置的结构示意图。如图6所示,该消息传输装置,包括:接收模块601、分组模块602、添加模块603、发送模块604、删除模块605和重新发送模块606;
其中,接收模块601,用于接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识。
分组模块602,用于根据接收方标识和当前日期信息,将消息报文进行分组。
添加模块603,用于针对分组内的各消息报文,为消息报文添加版本号;其中版本号为按照接收消息报文的顺序由先到后以自然数递增排列。
发送模块604,用于按照接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将添加版本号的消息报文添加至消息发送确认列表。
删除模块605,用于若在预设时长内接收到接收方客户端发送的确认回复信息、且确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同,则将消息发送确认列表中对应的消息报文删除。
重新发送模块606,用于若在预设时长内没有接收到接收方客户端发送的携带添加版本号的消息报文的版本号的确认回复信息,则将消息发送确认列表中对应的消息报文重新发送。
在一些实施例中,所述装置还包括:
第一更新模块607,用于若在预设时长内接收到接收方客户端发送的确认回复信息、且确认回复信息中携带的版本号与消息发送确认列表中的添加版本号的消息报文的版本号相同,则将消息发送确认列表中对应的消息报文删除之后,若确认回复信息中携带的版本号大于已接收版本号,则将维护表中的最新版本号更新为确认回复信息中携带的版本号。
第二更新模块608,用于若在预设时长内没有接收到接收方客户端发送的携带添加版本号的消息报文的版本号的确认回复信息,则将消息发送确认列表中对应的消息报文重新发送之后,若将消息发送确认列表中对应的消息报文重新发送预设次数失败或消息发送确认列表中的消息报文数量超过预设数量时,则确定接收方客户端状态异常,并以消息发送确认列表中的最小版本号更新维护表中的最新版本号并清空消息发送确认列表。
第二发送模块609,用于在确定接收方客户端异常状态结束后,则通过查询服务端的数据库,按照维护表中的最新版本号开始按版本号递增的顺序发送各消息报文。
在一些实施例中,所述装置还包括:
去重模块610,用于若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将消息发送确认列表中对应的消息报文重新发送之后,将消息发送确认列表中对应的消息报文重新发送至接收方客户端,以使接收方客户端根据消息报文与历史消息报文的报文数据特征值进行比对,若存在相同的报文数据特征值,则确定消息报文为重复发送的报文,接收方客户端不显示消息报文。
第一获取模块611,用于在确定任一接收方客户端离线后重新登录时,获取接收方客户端通过查询历史消息报文得到最新消息报文的版本号和日期信息;
第二获取模块612,用于根据最新消息报文的版本号和日期信息,通过查询服务端的数据库获取日期信息相同、版本号大于最新消息报文的版本号的消息报文,以及日期信息大于最新消息报文的日期信息的消息报文。
第二发送模块613,用于将查询得到消息报文发送至接收方客户端。
第三获取模块614,用于在确定任一接收方客户端离线后重新登录时,获取所述维护表中的最新版本号。
第四发送模块615,用于通过查询服务端的数据库,以维护表中的最新版本号开始按版本号递增的顺序获取相应的消息报文,并发送至接收方客户端。
第四获取模块616,用于在确定任一接收方客户端为首次登录时,通过查询服务端的数据库,获取以最大版本号开始由大到小的预设条数的消息报文,并发送至接收方客户端。
第二接收模块617,用于接收任一接收方客户端发送的消息查询请求,其中所述消息查询请求携带日期信息和版本号。
返回模块618,用于根据所述期信息和版本号查询服务端的数据库,获取对应的历史消息报文,并将历史消息报文返回给接收方客户端。
本申请实施例提供的消息传输装置,可用于执行上述实施例中消息传输方法的技术方案,其实现原理和技术效果类似,在此不再赘述。
需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,重新发送模块606可以为单独设立的处理元件,也可以集成在上述装置的某一个芯片中实现,此外,也可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上重新发送模块606的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
图7为本申请实施例提供的服务器的结构示意图。如图7所示,该服务器可以包括:收发器71、处理器72、存储器73。
处理器72执行存储器存储的计算机执行指令,使得处理器72执行上述实施例中的方案。处理器72可以是通用处理器,包括中央处理器CPU、网络处理器(network processor,NP)等;还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
存储器73通过系统总线与处理器72连接并完成相互间的通信,存储器73用于存储计算机程序指令。
收发器71可以用于获取待运行任务和待运行任务的配置信息。
系统总线可以是外设部件互连标准(peripheral component interconnect,PCI)总线或扩展工业标准结构(extended industry standard architecture,EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(randomaccess memory,RAM),也可能还包括非易失性存储器(non-volatile memory)。
本申请实施例提供的服务器,可以是上述实施例的终端设备。
本申请实施例还提供一种运行指令的芯片,该芯片用于执行上述实施例中消息传输方法的技术方案。
本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质中存储有计算机指令,当该计算机指令在计算机上运行时,使得计算机执行上述实施例消息传输方法的技术方案。
本申请实施例还提供一种计算机程序产品,该计算机程序产品包括计算机程序,其存储在计算机可读存储介质中,至少一个处理器可以从计算机可读存储介质读取计算机程序,至少一个处理器执行计算机程序时可实现上述实施例中消息传输方法的技术方案。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
Claims (11)
1.一种消息传输方法,其特征在于,应用于服务端,包括:
接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识;
根据所述接收方标识和当前日期信息,将所述消息报文进行分组;
针对分组内的各消息报文,为消息报文添加版本号;其中所述版本号为按照接收消息报文的顺序由先到后以自然数递增排列;
按照所述接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将所述添加版本号的消息报文添加至消息发送确认列表;
若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除;
若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送。
2.根据权利要求1所述的方法,其特征在于,所述服务端中存储有维护表,维护表用于记录接收方客户端已经接收到最新的消息报文的版本号,记为最新版本号;
所述若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除之后,还包括:
若所述确认回复信息中携带的版本号大于已接收版本号,则将所述维护表中的最新版本号更新为所述确认回复信息中携带的版本号;
相应地,所述若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送之后,还包括:
若将所述消息发送确认列表中对应的消息报文重新发送预设次数失败或所述消息发送确认列表中的消息报文数量超过预设数量时,则确定所述接收方客户端状态异常,并以所述消息发送确认列表中的最小版本号更新所述维护表中的最新版本号并清空所述消息发送确认列表;
在确定所述接收方客户端异常状态结束后,则通过查询服务端的数据库,按照所述维护表中的最新版本号开始按版本号递增的顺序发送各消息报文。
3.根据权利要求1或2所述的方法,其特征在于,若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送之后,还包括:
将所述消息发送确认列表中对应的消息报文重新发送至所述接收方客户端,以使所述接收方客户端根据所述消息报文与历史消息报文的报文数据特征值进行比对,若存在相同的报文数据特征值,则确定所述消息报文为重复发送的报文,接收方客户端不显示所述消息报文。
4.根据权利要求2所述的方法,其特征在于,还包括:
在确定任一接收方客户端离线后重新登录时,获取所述接收方客户端通过查询历史消息报文得到最新消息报文的版本号和日期信息;
根据所述最新消息报文的版本号和日期信息,通过查询服务端的数据库获取日期信息相同、版本号大于最新消息报文的版本号的消息报文,以及日期信息大于所述最新消息报文的日期信息的消息报文;
将查询得到消息报文发送至所述接收方客户端。
5.根据权利要求2所述的方法,其特征在于,还包括:
在确定任一接收方客户端离线后重新登录时,获取所述维护表中的最新版本号;
通过查询服务端的数据库,以维护表中的最新版本号开始按版本号递增的顺序获取相应的消息报文,并发送至接收方客户端。
6.根据权利要求2所述的方法,其特征在于,还包括:
在确定任一接收方客户端为首次登录时,通过查询服务端的数据库,获取以最大版本号开始由大到小的预设条数的消息报文,并发送至接收方客户端。
7.根据权利要求2所述的方法,其特征在于,还包括:
接收任一接收方客户端发送的消息查询请求,其中所述消息查询请求携带日期信息和版本号;
根据所述日期信息和版本号查询服务端的数据库,获取对应的历史消息报文,并将所述历史消息报文返回给接收方客户端。
8.一种消息传输装置,其特征在于,包括:
接收模块,用于接收不同发送方客户端发送的各消息报文,其中每条消息报文中携带接收方标识;
分组模块,用于根据所述接收方标识和当前日期信息,将所述消息报文进行分组;
添加模块,用于针对分组内的各消息报文,为消息报文添加版本号;其中所述版本号为按照接收消息报文的顺序由先到后以自然数递增排列;
发送模块,用于按照所述接收方标识,将任一添加版本号的消息报文发送至接收方客户端,并将所述添加版本号的消息报文添加至消息发送确认列表;
删除模块,用于若在预设时长内接收到接收方客户端发送的确认回复信息、且所述确认回复信息中携带的版本号与消息发送确认列表中的所述添加版本号的消息报文的版本号相同,则将所述消息发送确认列表中对应的消息报文删除;
重新发送模块,用于若在预设时长内没有接收到接收方客户端发送的携带所述添加版本号的消息报文的版本号的确认回复信息,则将所述消息发送确认列表中对应的消息报文重新发送。
9.一种服务器,其特征在于,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现如权利要求1-7中任一项所述的方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,所述计算机执行指令被处理器执行时用于实现如权利要求1-7中任一项所述的方法。
11.一种计算机程序产品,其特征在于,包括计算机程序,该计算机程序被处理器执行时实现权利要求1-7中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211041837.1A CN115412519B (zh) | 2022-08-29 | 2022-08-29 | 消息传输方法、装置、服务器及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211041837.1A CN115412519B (zh) | 2022-08-29 | 2022-08-29 | 消息传输方法、装置、服务器及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115412519A true CN115412519A (zh) | 2022-11-29 |
CN115412519B CN115412519B (zh) | 2024-05-03 |
Family
ID=84162484
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211041837.1A Active CN115412519B (zh) | 2022-08-29 | 2022-08-29 | 消息传输方法、装置、服务器及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115412519B (zh) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100070588A1 (en) * | 2008-09-15 | 2010-03-18 | Yahoo! Inc. | Reliability for instant messaging based on end point acknowledgements |
CN105871703A (zh) * | 2016-06-03 | 2016-08-17 | 用友网络科技股份有限公司 | 推拉结合的即时通信消息获取系统和方法 |
CN105978796A (zh) * | 2016-06-28 | 2016-09-28 | 乐视控股(北京)有限公司 | 基于不稳定移动网络的消息通信方法及系统 |
CN109067910A (zh) * | 2018-09-13 | 2018-12-21 | 乐蜜有限公司 | 一种消息拉取的方法及装置 |
CN109639564A (zh) * | 2018-12-12 | 2019-04-16 | 金瓜子科技发展(北京)有限公司 | 一种获取离线消息的方法、装置及计算机可读存储介质 |
WO2022089455A1 (zh) * | 2020-10-28 | 2022-05-05 | 百果园技术(新加坡)有限公司 | 消息获取方法、装置、设备及存储介质 |
-
2022
- 2022-08-29 CN CN202211041837.1A patent/CN115412519B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100070588A1 (en) * | 2008-09-15 | 2010-03-18 | Yahoo! Inc. | Reliability for instant messaging based on end point acknowledgements |
CN105871703A (zh) * | 2016-06-03 | 2016-08-17 | 用友网络科技股份有限公司 | 推拉结合的即时通信消息获取系统和方法 |
CN105978796A (zh) * | 2016-06-28 | 2016-09-28 | 乐视控股(北京)有限公司 | 基于不稳定移动网络的消息通信方法及系统 |
CN109067910A (zh) * | 2018-09-13 | 2018-12-21 | 乐蜜有限公司 | 一种消息拉取的方法及装置 |
CN109639564A (zh) * | 2018-12-12 | 2019-04-16 | 金瓜子科技发展(北京)有限公司 | 一种获取离线消息的方法、装置及计算机可读存储介质 |
WO2022089455A1 (zh) * | 2020-10-28 | 2022-05-05 | 百果园技术(新加坡)有限公司 | 消息获取方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN115412519B (zh) | 2024-05-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8792483B2 (en) | Method and device for rejecting redundantly retransmitted SIP messages | |
CN108449256B (zh) | 消息推送的处理方法、装置、计算机设备及存储介质 | |
CN109451032B (zh) | 一种消息传递系统 | |
CN109525376B (zh) | 快速重传方法、装置及终端设备 | |
CN109905479B (zh) | 文件传输方法和装置 | |
CN111970092B (zh) | 一种支持可靠性调节的多协议冗余网络异步通信方法 | |
CN109120385B (zh) | 一种基于数据传输系统的数据传输方法、装置及系统 | |
CN115412519B (zh) | 消息传输方法、装置、服务器及存储介质 | |
US11190301B2 (en) | Method and device for setting out-of-order value of network | |
US20110060957A1 (en) | Reliable Messaging Using Publish Subscribe Mechanism | |
CN109361629B (zh) | 一种基于Kafka大消息可靠传输方法 | |
CN111131498B (zh) | Url信息更新方法、缓存服务器、设备及存储介质 | |
CN113794622B (zh) | 消息处理方法、装置、电子设备及存储介质 | |
CN107563942B (zh) | 一种物流数据批量处理方法、物流处理系统以及处理装置 | |
CN113645008B (zh) | 一种基于链表的报文协议超时重发方法及系统 | |
CN106817680B (zh) | 推送短信的发送方法、短信中心以及系统 | |
CN109688204B (zh) | 基于ndn网络的文件下载方法、节点、终端 | |
CN111181628B (zh) | 通过北斗短报文传输语音数据的方法、终端及存储介质 | |
CN111078425B (zh) | 消息处理方法、装置、存储介质及电子设备 | |
CN108880994B (zh) | 一种重发邮件的方法和装置 | |
CN113810266B (zh) | 针对消息对象的重试操作方法、装置、设备及存储介质 | |
CN113347050B (zh) | 区块链节点退出节点集合的方法及装置 | |
US11836550B2 (en) | Systems and methods for moving, reconciling, and aggregating data from mainframe computers to hybrid cloud | |
CN113691614B (zh) | 资讯处理方法和装置 | |
CN115379400B (zh) | 群组短信回执的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |