CN103220206A - 一种消息发送方法、装置和一种消息接收方法、装置 - Google Patents
一种消息发送方法、装置和一种消息接收方法、装置 Download PDFInfo
- Publication number
- CN103220206A CN103220206A CN2012100177712A CN201210017771A CN103220206A CN 103220206 A CN103220206 A CN 103220206A CN 2012100177712 A CN2012100177712 A CN 2012100177712A CN 201210017771 A CN201210017771 A CN 201210017771A CN 103220206 A CN103220206 A CN 103220206A
- Authority
- CN
- China
- Prior art keywords
- message
- client
- identifier
- message identifier
- ordering
- 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
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请提供了一种消息发送方法、装置和一种消息接收方法、装置,涉即时通讯领域。本申请的方法包括:将待发送的各消息按先后顺序分配一个消息标识;根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包并发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收由所述客户端发送的信息中获得。在通过本申请服务器只需根据接收到的所述消息标识即可确认发送的一批消息是否接收成功,无需对每条消息进行确认,只需将消息标识之后至少一个最靠近该消息标识的消息打包发送即可,使客户端能按顺序接收消息,大幅降低了服务器开销。
Description
技术领域
本申请涉即时通讯领域,特别是涉及一种消息发送方法、装置和一种消息接收方法、装置。
背景技术
在现今的网络通讯系统中,客户端接收服务器发送的消息,服务器将接收到的待发送给相应客户端的消息发送给相应客户端。比如在线客服,在线客服是一种基于文字和多媒体的在线即时交互的客户服务方式,客户端通过浏览器和客服人员进行沟通,不需要专门安装相关客户端软件,通过浏览器从服务器接收消息的方式实现客户端的消息接收。
在客户端接收消息的过程中,存在各种不确定因素,包括服务器异常,网络不稳定、网络丢包、客户端浏览器解析消息异常等,这些不确定因素都有可能导致某一条消息的丢失。而对于服务提供方来说,消息丢失的情况是一个非常严重的问题,需要尽量避免。比如对于在线客服来说,是不允许消息丢失的情况发生的,因为丢失消息容易造成客户端对服务内容的误解。
现有技术中,客户端需要向服务器发送接收消息的请求信息,同时为了检验消息是否接收正常,需要在每次接收到消息后,向服务器发送一个消息,服务器标记该消息已经被成功接收;服务器处理所有客户端对于接收成功消息的确认信息,并定期检测所有未被确认的消息,如果超过一定的时间则进行重发。现有技术如表一所述:
表一
假设服务器的检测周期为10秒,服务器将客户端接收失败的消息进行重新发送的时间段阈值为10秒。如表一,在服务器10:10进行检测时:A1的接收失败时间为1秒,不超过10秒,服务器不重新发送A1。
在服务器10:20进行检测时:客户端对A1的接收失败时间为11秒,超过10秒,服务器重新发送A1;客户端对A2接收成功;户端对A3的接收失败时间为2秒,服务器不重新发送A3。如果此时客户端对A1接收成功,则A1在A2之后。
在上述模式下,服务器的负载倍增,如服务器根据客户端的n条请求信息如发送了n条消息,客户端又需要发送n条确认信息到服务器端,在此过程中,服务器需要处理n条消息的消息确认。同时,如果存在客户端未接收的消息,服务器还需要轮询检测所有未接收的消息是否超时,在要求消息按顺序送到的情况下,该消息重发模式并不能保证消息的接收顺序,并且这种消息发送方法,导致服务器开销巨大。
发明内容
本申请提供一种消息发送方法、装置和一种消息接收方法、装置,以解决在各种复杂的环境下,确保客户端收到消息数据,而且不增加服务器的复杂程度和负载,并降低服务器开销。
为了解决上述问题,本申请公开了一种消息发送方法,包括:
将待发送的各消息按先后顺序分配一个消息标识;
根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包并发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收由所述客户端发送的信息中获得。
优选的,通过以下方式将待发送的各消息按先后顺序分配一个消息标识:
依照服务器端接收消息的顺序,将所述消息按所述顺序分配一个消息标识。
优选的,通过以下方式将待发送的各消息按先后顺序分配一个消息标识:
根据消息中对应的待接收客户端标识,按服务器对带有所述待接收客户端标识的消息的接收顺序将所述消息分配一个消息标识。
优选的,还包括:
根据客户端发送的消息标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。
优选的,在根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包之后之前包括:
接收客户端发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
优选的,在根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包之后包括:
接收客户端发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
优选的,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包发送给该客户端的过程中,还包括:
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M小于等于阈值N时,将各消息一起打包生成消息包并发送给客户端;所述N为大于1的整数;
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时,将各消息按先后顺序分组打包生成消息包并送给客户端;其中,每个消息包的条数小于等于N。
优选的,当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时:
将M条消息按先后顺序分为[M/N]+1组。
相应的本申请公开了一种消息接收方法,包括:
接收服务器端发送的消息包;所述消息包为在服务器端中对应于该客户端的排序最靠后的消息标识顺序之后的至少一个最靠近该消息标识的消息打包生成的;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的确认信息获得;
从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识。
优选的,在接收服务器端发送的消息包之前还包括:
发送请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
优选的,从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识之后还包括:
发送确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
相应的,本申请公开了一种消息发送装置,包括:
消息标识模块,用于将待发送的各消息按先后顺序分配一个消息标识;
请求接收模块,用于根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包并发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收到的由所述客户端发送的确认信息获得。相应的,本申请一种消息接收装置,其特征在于,包括:消息接收模块,用于接收服务器端发送的消息包;所述消息包为在服务器端中所述排序最靠后的消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成的;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的信息获得;解析模块,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。
与现有技术相比,本申请包括以下优点:
本申请由服务器端首先将待发送的各消息按先后顺序分配一个消息标识,然后根据接收的客户端发送的收消息的请求和消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端。客户端发送收消息的请求并将当前记录的消息标识也一发送给服务器端,然后将接收到的由服务器端发送的消息包进行解析,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识,下一次发起确认信息时再将最后更新的消息标识发送到服务器端。在本申请这个过程中,服务器只需根据接收到的所述消息标识即可确认发送的一批消息是否接收成功,无需对每条消息进行确认,并且只需将消息标识之后至少一个最靠近该消息标识的消息打包发送即可,无需判断接收失败的消息是否超时,使客户端能按顺序接收消息,这大幅降低了服务器开销。
附图说明
图1是本申请一种消息发送方法的流程示意图;
图2是本申请消息在服务器端的存放示例;
图3是本申请一种消息接收方法的流程示意图;
图4是本申请一种消息发送装置的结构示意图;
图5是本申请一种消息接收装置的结构示意图;
图6是本申请一种消息传输装置的结构示意图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请由服务器端首先将待发送的各消息按先后顺序分配一个消息标识,然后根据接收的客户端发送的收消息的请求和消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端。客户端发送收消息的请求并将当前记录的消息标识也一发送给服务器端,然后将接收到的由服务器端发送的消息包进行解析,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识,下一次发起确认信息时,再将最后更新的消息标识发送到服务器端。在本申请这个过程中,客户端只需要发送包括成功接收到最靠后的消息标识的请求信息到服务器,即所述请求信息中包含每次接收的消息中排序最靠后的消息标识,就可以实现在不增加服务器的复杂程度和负载的情况下,使客户端按顺序接收消息,这有效降低了服务器开销。
参照图1,其示出了本申请一种消息发送方法的流程示意图,包括:
步骤110,为待发送的各消息按先后顺序分配一个消息标识。
在实际应用中,比如在线即时通讯系统中,服务器端首先会接收需要发送给客户端的消息,例如在线客服。又比如,在移动通信系统中,服务器会接收需要发送给客户端(如手机等移动终端的客户端)的消息。
服务器端首先会接收所有发送给各客户端的消息,然后可以通过服务器端将这些消息按先后顺序分配一个消息标识。其中,服务器端可根据接收到的各个消息所对应的客户端标识,确认该消息需要发送给哪个或哪些客户端。
优选的,可以依照服务器端接收消息的顺序或者根据消息自身的发送顺序,将所述消息按所述顺序分配一个消息标识。
在实际的操作过程中,可以采取能够进行自增长的存储方式来存储消息,然后根据自增长或者类似的消息标识机制返回对应的主键id,并将该主键id作为该消息的标识号。
例如采用mysql或者oracle数据库,缓存存储可以采用memcache(一种高性能的分布式的内存对象缓存系统),redis(一种关键值存储系统)等类似存储系统。
所有消息在被发送到服务器端后,可按先后顺序分配一个消息标识,比如说分配一个数字标号,这个数字标号不会重复,并且按照先后顺序递增或递减。参照图2,其为消息在服务器端的存放示例。在本示例中采用递增的方式,服务器端的全局递增计数器按服务器接收消息的顺序,每接收一个,给此消息分配一个比前面一个消息大1的消息标识。例如,服务器对第1个接收的发送给客户端A的消息分配一个数字标号1,对第2个接收的发送给客户端B的消息分配一个数字标号2,对第1000个接收的发送给客户端A的消息分配一个数字标号1000,依此类推。其中,全局数据递增计数器的初始值为一般为0,显然初始值也可以是其他值。
另外,还可以根据消息中对应的待接收客户端标识,按服务器对带有所述客户端标识的消息的接收顺序将所述消息分配一个消息标识。
在实际中,如前所述,每个消息都会对应一个待接收客户端的标识,以标识该消息发送给对应的客户端。因此,可以根据消息所属的客户端为组,按服务器中对应该客户端的消息的接收顺序将所述消息分配一个消息标识。
该实现方式跟全局消息的消息标识不同的地方在于,每个用户接收的消息标识都是连续的,各个用户之间不影响,在使用上更加的独立和可靠。
在实际的操作过程中,分用户组实现消息的消息标识的自增长,可以采用如下方式来实现:
在消息的存储设计上,将消息实体设计上采用如下格式设计:
在发送消息的时候,messageId每次插入的时候都根据上一个messageId+1;类似的实现流程为:
MessageId=GetLastMessageId(#receiveToken#)
InsertMessage(#receiveToken#,MessageId+1)
其中:receiveToken为接收消息客户端的标识,即:用来标示该消息是发送给谁的,实际实现中接收消息客户端的标识receiveToken可以采用receiveUserId(接收消息客户端id)或者receiveUserName(接收消息客户端姓名)等来实现根据消息中对应的待接收客户端标识,按服务器对带有所述客户端标识的消息的接收顺序将所述消息分配一个消息标识。
通过这种方式来实现根据接收者分组对消息进行标识。
服务器接收所有被发送过来的消息,而每条消息都包括了对应客户端的标识,服务器可根据各消息中的客户端标识将各消息发送给相应客户端,因此可以根据消息中对应的待接收客户端标识,按服务器对带有所述客户端标识的消息的接收顺序将所述消息分配一个消息标识。
比如,将发送给客户端A的消息按顺序分配消息标识A1、A2、A3……,将发送给客户端B的消息按顺序分配消息标识B1、B2、B3……。
其中,所述消息标识可以为数字消息标识形式,也可以为其他形式,只要该消息标识具有顺序性,服务器对该消息标识具有可识别性即可,本申请对消息标识的具体形式不进行限定。
步骤120,根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收到的由所述客户端发送的确认信息获得。
优选的,在根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包之后之前包括:
步骤m11,接收客户端发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
在实际中,客户端首先会与服务器建立连接。在第一次连接时,可在客户端首先进行初始化,使客户端最初记录的消息标识为排序在服务器所有标识之前的标识,比如服务器给各消息分配标识从数字1开始从小到大逐个分配时,那么客户端在第一次发送请求信息时可初始化自己当前记录的消息标识为0,并将该0值发送到服务器,服务器则根据0值,将排序在0之后对应该客户端至少一个最靠近该消息标识的消息打包发送给该客户端。
另外,客户端可在与服务器建立连接时将自己的客户端标识发送至服务器端。即服务器端被动等待客户端的带收消息请求性质的请求信息,然后根据客户端发送的请求信息在发送消息包。
然后,再执行步骤m12,根据所述客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端。
在实际中,客户端可以使用长轮询或者短轮询的方式向服务器端发送请求信息,所述请求中包括当前记录的排序最靠后的消息标识和客户端标识。在实际中,客户端可设置一个变量,用于存储排序最靠后的消息标识。客户端每次轮询时发起收消息的请求给服务器端,并告知服务器本客户端的客户端标识和当前变量中存储的消息标识,所述消息标识包含在这个请求中。比如一客户端发起收消息的请求时,即通过消息标识和客户端标识告知服务器本客户端当前所收到消息中最大的消息的消息标识,即告知服务器当前该客户端收到的排序最后一条的消息的消息标识是多少。
其中,当前该客户端收到的排序最后一条的消息的消息标识在客户端消息接收成功后才会更新。其过程如下:
在发送请求信息后,首先接收服务器端发送的消息包;所述消息包为服务器端中在所述排序最靠后的消息标识顺序之后对应于该客户端的消息。
然后,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。如此循环操作。
对于所述消息包中的消息,客户端可按消息标识顺序逐条解析消息内容,并呈现给客户端。并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。比如客户端当前记录的消息标识为40,收到消息包后,消息包中排序最靠后的消息标识为80,则将当前记录的消息标识40更新为消息标识80。然后下一轮发起收消息的请求时则将该消息标识80发送给服务器端。
在客户端接收消息的过程中,如果接收消息失败,则当前的消息标识不更新。比如前述客户端当前记录的消息标识为40,然后接收到了一个服务器发送的消息包,其中排序最靠后的消息标识为80,但因为客户端对该消息的接收失败,则当前的消息标识仍然为40,在下次轮询发送确认信息时继续将该消息标识发送给服务器。
当客户端发送某个消息标识到服务器端时,说明客户端对在该消息标识之前的消息已经正确接收,并且按顺序解析。
服务器根据客户端发送的请求信息中当前记录的排序最靠后的消息标识和客户端标识,在服务器端查询客户端标识对应的客户端的消息,以附加条件为消息的消息标识顺序大于该排序最靠后的消息标识,并将符合附加条件的消息打包发送给对应客户端标识对应的客户端。
具体的,服务器接收到客户端发送的请求信息后(其中所述请求信息中包括客户端当前记录的排序最靠后的消息标识和客户端标识),在服务器端查询客户端标识对应所述客户端的消息,对于服务器端所有消息标识顺序大于所述请求中排序最靠后消息标识的消息,可将其按先后顺序排列。即服务器接收到客户端的确认信息和客户端的排序最靠后的消息标识后,可以以消息的消息标识顺序大于所述变量中的消息标识为条件,在服务器中查询对应客户端的消息,并按先后顺序将这些消息排序。
比如,服务器根据前述获得的一客户端的消息标识和客户端标识,在服务器中查询数字标号大于此消息标识发送给此客户端标识对应客户端的消息,并将这些消息按数值按数字标号排序。比如当前消息标识的值为80和客户端标识A,服务器端所有待发送消息中待发送给客户端A的消息有消息标识为60、100、110、115、200这五条消息,则服务器将大于80的消息标识为100、110、115、200这四条消息按从小到大的顺序进行排序。如此,根据客户端发送的排序最靠后的消息标识和客户端标识,服务器将其中在该消息标识后的消息打包发送给客户端标识对应的客户端,保证客户端能接收服务器当前消息顺序之后的所有消息,并可按顺序解析,保证了客户端正确的接收消息。
若使用数据库存储消息时,SQL查询并排序语句是select*frommessage where user=?And id>maxid order by id。其中,maxid表示消息标识。
然后,将所述排序后的所有消息打包发送给客户端标识对应的客户端。
其中,打包时,可以按消息标识的先后顺序打包,以便客户端接收到该消息包后进行解析。比如,从步骤120,服务器得到发送给客户端A的排序后的消息标识为100、110、115、200四条消息,则服务器将这四条排好序的消息一起发送给客户端A。
其中,当服务器在上一次客户端轮询发送请求信息后,服务器根据其请求信息中的消息标识和客户端标识发送消息包到该客户端时,该客户端因为网络中断或者其他原因导致对该消息包未接收成功,那么客户端通讯正常后再次将其发送确认信息时还会将客户端异常前记录的消息标识发送给服务器(在实际中,可以在客户端通过设置一个变量,用于存储当前收到消息中排序最靠后的消息标识),此时,如果服务器端又接收到了新的发送给该客户端的消息,则服务器端将的新的消息和原有在客户端异常前记录的消息标识顺序后的消息一起打包发送给客户端。比如当服务器发将已排序的标号为100、110、115、200四条消息一起发送给客户端A,但该消息在发送过程中丢失或者其他原因导致客户端接收这些消息失败,客户端A通讯正常后继续将异常前记录的消息标识为80这个数值发送给服务器,但在这个过程中,服务器接收到了2个新的发送给客户端A的标号为350、400的两个消息,则在步骤A2中,服务器会将消息标识350、400的这两个消息也加入排序,排序后的消息标识为100、110、115、200、350、400这六条消息,然后服务器将这6条消息一起打包再发送给客户端A。客户端在成功接收到这个消息包后,可根据该消息包中消息的排序逐个解析每条消息。
或者,优选的,本申请还可包括一种消息发送方法:
首先执行步骤n11,根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端。
在实际中,客户端首先会与服务器建立连接。本申请也可在第一次连接时,此时客户端还未接收任何消息。此时首先由服务器初始化自己当前记录的消息标识,该消息标识比当前分配给接收到的消息的消息标识顺序都靠前。比如客户端将当前接收到的消息标识按1,2……N逐步增大分配,那么可初始化服务器端当前记录的消息标识为0,对于0之后对于某客户端的的最靠近0的至少一个消息打包发送给该客户端。其中,同时客户端也初始化当前记录的消息标识为0,这样可以保证客户端可以准确接收服务器端的消息包,而不至于如果第一次接收失败后错误接收所述消息包。
然后服务器端将后续接收的客户端发送客户端记录的当前排序最靠后的消息标识更新为服务器端当前记录的消息标识。
在上述过程中,客户端首先接收服务器端发送的消息包;所述消息包为服务器端中在所述排序最靠后的消息标识顺序之后对应于该客户端的消息。
然后,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。其解析过程与前述描述基本相同。
然后在转入向服务器端发送确认信息的步骤。
其中服务器端在查询比其当前记录的消息标识排序靠后的对应与某客户端的方法与前述基本相同,在此不在赘叙。
再执行步骤n12,接收客户端发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
当客户端成功接收服务器发送的消息包后,将所述消息包中排序最好后的消息的消息标识发送给服务器端,以确认该客户端接收到服务器端发送的消息包。
即服务器端根据当前记录的消息标识主动发送消息包至客户端,然后根据客户端发送的确认信息确认客户端成功接收并更新当前记录的消息标识。
在实际中,在服务器端可记录当前接收到的客户端发送的排序最靠后的消息包,其中,在客户端与服务器端第一次交互时,初始化服务器端记录的消息标识为比其分配的消息标识的排序最靠前的消息标识。在客户端可记录当前接成功接收到的消息包中的排序最靠后的消息的消息标识,然后将该消息标识发送给服务器端。
其中,优选的,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端时:
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M小于等于阈值N时,将各消息一起打包发送给客户端。
比如,如果服务器最多只能一次打包发送10条消息给客户端,那么服务器接收到客户端的消息标识之后,查询到服务器中对应该客户端的消息为9条,那么即可将该9条消息打包发送给对应客户端。
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时,将各消息按先后顺序分组发打包送给客户端;其中,每组消息的条数小于等于N。
比如对于前述服务器最多只能一次打包发送10条消息给客户端,那么那么服务器接收到客户端的消息标识之后,查询到服务器中对应该客户端的消息为16条,那么服务器即可将该16条消息按顺序分组打包发送给客户端,比如该16条消息的消息标识分别为1、2、3、……16,那么可将1~5号作为第一组,6~10号作为第2组,11~16号作为第3组,然后首先发送第一组到对应客户端,客户端对第一组接收成功,再发送第二组,依此类推。
其中,当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时:将M条消息按先后顺序分为[M/N]+1组。比如前述16条消息,服务器最多只能一次打包发送10条消息给客户端,那么可将16条消息分为[16/10]+1=2组。在实际中排序靠前的组中消息的条数一般等于阈值,比如前述例子中将16条消息分为2组时,第一组包括1~10号消息;第二组包括11~16号消息。如此可尽量快速的将消息发送给客户端。其中[M/N]标识对M/N的结果向下取整,比如M/N的结果为9.5,那么[M/N]=9。
在实际中,分为[M/N]+1组时,前[M/N]组的消息包的消息条数一般为阈值N条。
优选的,还可以包括步骤130,根据客户端发送的消息标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。如果客户端发送了消息标识,说明客户端成功接收了该消息标识之前的所有消息,那么即可将服务器中该消息之前的消息进行删除。
比如当服务器收到一客户端当前的消息标识为消息标识80和客户端标识A,说明客户端A已经将消息标识80以前的消息成功按顺序接收,这时即可将80以前的对应该客户端A的消息进行删除,比如前述例子中服务器中存在60、100、110、115、200这五条待发送给客户端A的消息,但当前的消息标识为80,这时即可将发送给客户端A的消息标识为60的消息删除。如此可以节省服务器端的存储空间,提升服务器的性能。
参照图3,其示出了本申请的一种消息接收方法的流程示意图,包括:
步骤210,向服务器端发送请求信息,所述请求信息中包括当前记录的排序最靠后的消息标识和客户端标识。
客户端可以使用长轮询或者短轮询的方式向服务器端发送请求信息通知服务器端发送消息,所述请求信息中包括当前记录的排序最靠后的消息标识和客户端标识。客户端每次轮询时发送请求信息给服务器端,并告知服务器本客户端当前变量中存储的消息标识,所述消息标识包含在这个请求中,在这个过程中也讲客户端自己的客户端标识也发送到服务器。比如客户端发送请求信息时,告知服务器本客户端当前所收到消息中最大的消息的消息标识和该客户端的客户端标识,即告知服务器当前该客户端收到的排序最后一条的消息的消息标识是多少。
步骤220,接收服务器端发送的消息包;所述消息包为在服务器端中所述排序最靠后的消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息。
在实际中,客户端首先会与服务器建立连接。在第一次连接时,可在客户端首先进行初始化,使客户端最初记录的消息标识为排序在服务器所有标识之前的标识,比如服务器给各消息分配标识从数字1开始从小到大逐个分配时,那么客户端在第一次发送请求信息时可初始化自己当前记录的消息标识为0,并将该0值发送到服务器,服务器则根据0值,将排序在0之后对应该客户端至少一个最靠近该消息标识的消息打包发送给该客户端。
即客户端主动发送请求信息至服务器端要求收消息,服务器端根据所述请求信息中客户端成功接收的排序最靠后的消息标识将服务器端的对应该客户端的最靠近该消息标识的至少一个消息打包发送给该客户端。
步骤230,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。
对于所述消息包中的消息,相应客户端可按消息标识顺序逐条解析消息内容,并呈现在该客户端的展示界面。并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。比如步骤210中当前记录的消息标识为40,收到消息包后,消息包中排序最靠后的消息标识为80,则将当前记录的消息标识40更新为消息标识80。然后下一轮发起收消息的请求时则将该消息标识80发送给服务器端。
优选的,在接收到服务器端发送的消息包后包括:在客户端判断是否成功接收所述消息;如果失败,则转入步骤210;如果成功,则转入步骤230。
在整个过程中,某个客户端可轮询发送请求信息到服务器端,当该客户端接收消息失败时,该客户端下次轮询继续将当前记录的消息标识发送到服务器端,因为接收消息失败,那么该消息标识保持不变。其中,如果在这个过程中,服务器接收到新的发送给该客户端的消息,该客户端会接收到服务器端将新的消息一起打包发送的消息包。比如当服务器发将已排序的标号为100、110、115、200四条消息一起发送给客户端A,但该消息在发送过程中丢失或者其他原因导致客户端接收这些消息失败,客户端A继续将消息标识为80这个数值发送给服务器,但在这个过程中,服务器接收到了2个新的发送给客户端A的标号为350、400的两个消息,则服务器会将消息标识350、400的这两个消息也加入排序,排序后的消息标识为100、110、115、200、350、400这六条消息,服务器再将这6条消息一起打包再发送给客户端A。
其中,可在客户端设置一个变量,用于记录客户端当前所接收消息中排序最靠后的消息标识,比如变量maxid,当客户端所接收的消息中排序最靠后的消息标识为40时,maxid=40(即消息标识为40);当当客户端所接收的消息中排序最靠后的消息标识为100时,maxid=100(即消息标识为40)。
其中,在系统开始接收所有消息之前,在客户端初始化maxid记录为空值。比如,如果以maxid为消息标识,则将初始的maxid记录初始化为0,如此,则可保证客户端能从最小的maxid开始接收消息,而不至于遗漏掉maxid小的消息(即在整个消息排序中排序靠前的消息)。
或者,优选的,本申请还可包括一种消息接收方法:
从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识之后包括:
步骤P210,接收服务器端发送的消息包;所述消息包为在服务器端中对应于该客户端的排序最靠后的消息标识顺序之后的至少一个最靠近该消息标识的消息打包生成的;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的确认信息获得。
步骤P220从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识。
步骤P230,发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
在实际中,客户端首先会与服务器建立连接。本申请也可在第一次连接时,此时客户端还未接收任何消息。此时首先由服务器初始化自己当前记录的消息标识,该消息标识比当前分配给接收到的消息的消息标识顺序都靠前。比如客户端将当前接收到的消息标识按1,2……N逐步增大分配,那么可初始化服务器端当前记录的消息标识为0,对于0之后对于某客户端的的最靠近0的至少一个消息打包发送给该客户端。其中,同时客户端也初始化当前记录的消息标识为0。
即客户端被动等待服务器端发送消息包,然后客户端接收消息包成功后,将成功接收的消息包中的排序最靠后的消息的消息标识发送给服务器端。继续等待服务器下次发送的消息包。
如下所示,为本申请优选的的一种消息传输过程:
步骤S110,将待发送的各消息按先后顺序分配一个消息标识。比如参照图2的对消息的消息标识方式,从服务器接收到的第一条消息开始,通过全局递增计数器给每一个服务器接收到的消息分配一个消息标识(在此即为消息标识)。
步骤S120,客户端向服务器端发送请求信息,所述请求信息中包括当前记录的排序最靠后的消息标识和客户端标识;
步骤S130,服务器端接收客户端发送的请求信息,所述请求信息中包括当前记录的排序最靠后的消息标识和客户端标识。
步骤S140,服务器端根据所述排序最靠后的消息标识和客户端标识,将服务器端中在该排序最靠后消息标识之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端。
步骤S150,客户端收接收所述消息包,并判断是否接收成功:
如果不成功,转入步骤120;此时客户端会继续将当前消息标识发送给服务器端,即消息标识没变化,服务器端会继续依据该消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端;
如果成功,转入步骤S160。
步骤S160,从所述消息包中逐条解析消息,呈现给用户,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。比如步骤120中的消息标识为0,服务器端将其中对应于该客户端的10、17、20、21、25这五条消息标识大于0的消息打包发送给客户端,客户端成功解析后,就将当前记录的消息标识0更新为消息标识25。
此次轮询的消息接收完毕,则可继续转入步骤120进行下一次轮询的消息接收过程。
采用上述消息传输的过程可以有效解决确保首先被客户端接受并处理,同时也可以保证消息是按顺序接受,其中也包含了消息收取失败后的自动重收的功能。比如当有两条给客户端A的消息被成功发送的服务器,两条消息标识分别是203,215。此时客户端第一次去收取消息,将自己的客户端标识和存储的消息标识发送给服务器,服务器根据客户端标识和消息标识成功返回结果(由于消息标识为0,所有203和215号消息都被返回),但是在消息传输过程中消息丢失了,导致该客户端收消息失败。当失败后客户端重新轮询发起收取消息请求,由于该客户端消息标识没有被修改,所以第二次收取消息的时候,203和215号消息依然被服务器返回。若第二次该客户端接受成功,那么消息标识被更新为215。那么第三次收取消息的时候就不会重复收取203和215这两个消息。其中如果第二此收取消息时,服务器端接收到了新的对应该客户端的消息231,则服务器将203、215、231这三个已在服务器排序的消息返回给该客户端,该客户端如果接收成功,那么消息标识被更新为231。
另外,客户端在第一次与服务器端连接时包括步骤S100,在客户端开始准备接收消息时,在客户端先初始化其当前记录消息标识为空值。比如,若以数字消息标识为消息标识,则初始化数字消息标识为0。
另外,服务器端在步骤S140之后还包括:步骤S170,根据客户端发送的消息标识和客户端标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。
参照图4,其示出了一种消息发送装置,包括:
消息标识模块310,用于将待发送的各消息按先后顺序分配一个消息标识;
消息发送模块320,用于根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收到的由所述客户端发送的确认信息获得。
其中,在所述消息发送模块320之前还包括第一信息接收模块,接收客户端发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
或者,在所述消息发送模块320之后还包括第二信息接收模块,接收客户端发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
还包括:消息删除模块,用于根据客户端发送的消息标识和客户端标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。
参照图5,其示出了一种消息接收装置,包括:
消息接收模块410,用于接收服务器端发送的消息包;所述消息包为在服务器端中所述排序最靠后的消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的确认信息获得。
解析模块420,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。
其中在消息接收模块410之前还包括:第一信息发送模块,用于发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
或者,在解析模块420,之后还包括:第二信息发送模块,用于发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
其中所述的消息接收模块还可用于判断是否成功接收所述消息;如果失败,则转入请求发送模块;如果成功,则转入解析模块;
参照图6,其示出了一种消息传输系统,包括:服务器端和客户端;
所述服务器端包括:
消息标识模块510,用于将待发送的各消息按先后顺序分配一个消息标识;
消息发送模块550,用于根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收到的由所述客户端发送的确认信息获得;
其中,在所述消息发送模块550之前还包括第一信息接收模块,接收客户端发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
或者,在所述消息发送模块550之后还包括第二信息接收模块,接收客户端发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。所述的客户端包括:
消息接收模块540,用于用于接收服务器端发送的消息包;所述消息包为在服务器端中所述排序最靠后的消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的确认信息获得;
所述消息接收模块540还可用于判断是否成功接收所述消息;如果失败,则转入请求发送模块;如果成功,则转入解析模块;
解析模块560,用于从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。
其中在消息接收模块540之前还包括:第一信息发送模块,用于发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
或者,在解析模块560之后还包括:第二信息发送模块,用于发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。其中,所述服务器端还包括消息删除模块,用于根据客户端发送的消息标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。
对于系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
以上对本申请所提供的一种消息发送方法、装置和一种消息接收方法、装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (13)
1.一种消息发送方法,其特征在于,包括:
将待发送的各消息按先后顺序分配一个消息标识;
根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包并发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收由所述客户端发送的信息中获得。
2.如权利要求1所述的方法,其特征在于,通过以下方式将待发送的各消息按先后顺序分配一个消息标识:
依照服务器端接收消息的顺序,将所述消息按所述顺序分配一个消息标识。
3.如权利要求1所述的方法,其特征在于,通过以下方式将待发送的各消息按先后顺序分配一个消息标识:
根据消息中对应的待接收客户端标识,按服务器对带有所述待接收客户端标识的消息的接收顺序将所述消息分配一个消息标识。
4.如权利要求1所述的方法,其特征在于,还包括:
根据客户端发送的消息标识,将服务器端中在该消息标识顺之前的对应于该客户端的消息进行删除。
5.如权利要求1所述的方法,其特征在于,在根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包之后之前包括:
接收客户端发送的请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
6.如权利要求1所述的方法,其特征在于,在根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包之后包括:
接收客户端发送的确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
7.如权利要求1所述的方法,其特征在于,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包发送给该客户端的过程中,还包括:
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M小于等于阈值N时,将各消息一起打包生成消息包并发送给客户端;所述N为大于1的整数;
当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时,将各消息按先后顺序分组打包生成消息包并送给客户端;其中,每个消息包的条数小于等于N。
8.如权利要求7所述的方法,其特征在于,当服务器端中在该消息标识顺序之后对应于该客户端的消息条数M大于阈值N时:
将M条消息按先后顺序分为[M/N]+1组。
9.一种消息接收方法,其特征在于,包括:
接收服务器端发送的消息包;所述消息包为在服务器端中对应于该客户端的排序最靠后的消息标识顺序之后的至少一个最靠近该消息标识的消息打包生成的;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的确认信息获得;
从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识。
10.如权利要求9所述的方法,其特征在于,在接收服务器端发送的消息包之前还包括:
发送请求信息,所述请求信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
11.如权利要求9所述的方法,其特征在于,从所述消息包中逐条解析消息,并将当前记录成功接收的消息的消息标识更新为所获得消息中排序最靠后的消息的消息标识之后还包括:
发送确认信息,所述确认信息包括客户端标识和该客户端成功接收的消息中排序最靠后消息的消息标识。
12.一种消息发送装置,其特征在于,包括:
消息标识模块,用于将待发送的各消息按先后顺序分配一个消息标识;
请求接收模块,用于根据客户端标识和与该客户端对应的排序最靠后的消息标识,将服务器端中在该消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成消息包并发送给该客户端;其中,所述该客户端对应的排序最靠后的消息标识通过接收到的由所述客户端发送的确认信息获得。
13.一种消息接收装置,其特征在于,包括:
消息接收模块,用于接收服务器端发送的消息包;所述消息包为在服务器端中所述排序最靠后的消息标识顺序之后对应于该客户端的至少一个最靠近该消息标识的消息打包生成的;其中,所述在服务器端中所述排序最靠后的消息标识通过客户端发送的信息获得;
解析模块,从所述消息包中逐条解析消息,并将当前记录的消息标识更新为所获得消息中排序最靠后的消息标识。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210017771.2A CN103220206B (zh) | 2012-01-19 | 2012-01-19 | 一种消息发送方法、装置和一种消息接收方法、装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210017771.2A CN103220206B (zh) | 2012-01-19 | 2012-01-19 | 一种消息发送方法、装置和一种消息接收方法、装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103220206A true CN103220206A (zh) | 2013-07-24 |
CN103220206B CN103220206B (zh) | 2017-04-19 |
Family
ID=48817688
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210017771.2A Active CN103220206B (zh) | 2012-01-19 | 2012-01-19 | 一种消息发送方法、装置和一种消息接收方法、装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103220206B (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104683288A (zh) * | 2013-11-26 | 2015-06-03 | 腾讯科技(北京)有限公司 | 消息续传方法和装置 |
CN104954446A (zh) * | 2015-05-28 | 2015-09-30 | 北京中亦安图科技股份有限公司 | 消息推送方法及系统 |
CN105306348A (zh) * | 2015-11-10 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 群聊延漏消息的解决方法以及即时通讯工具 |
CN105450365A (zh) * | 2014-08-20 | 2016-03-30 | 北大方正集团有限公司 | 消息发送和消息接收装置及其方法和消息交互系统 |
CN105487963A (zh) * | 2015-11-26 | 2016-04-13 | 小米科技有限责任公司 | 消息确认方法及装置 |
CN105812235A (zh) * | 2016-03-04 | 2016-07-27 | 百度在线网络技术(北京)有限公司 | 消息处理方法、装置及系统 |
CN105956889A (zh) * | 2016-06-07 | 2016-09-21 | 乐视控股(北京)有限公司 | 广告监测方法、装置及系统 |
CN105978796A (zh) * | 2016-06-28 | 2016-09-28 | 乐视控股(北京)有限公司 | 基于不稳定移动网络的消息通信方法及系统 |
CN106331094A (zh) * | 2016-08-23 | 2017-01-11 | 惠州市拉维尼科技有限公司 | 转发方法 |
CN106331093A (zh) * | 2016-08-23 | 2017-01-11 | 惠州市拉维尼科技有限公司 | 数据发送方法 |
CN106921554A (zh) * | 2015-12-24 | 2017-07-04 | 北京新媒传信科技有限公司 | 消息传输方法及装置 |
CN107040563A (zh) * | 2016-02-04 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 异步服务处理方法及服务器 |
WO2017162045A1 (zh) * | 2016-03-23 | 2017-09-28 | 阿里巴巴集团控股有限公司 | 一种消息的发送方法和终端设备 |
CN110602245A (zh) * | 2019-09-26 | 2019-12-20 | 福建天泉教育科技有限公司 | 提高应用软件吞吐量的方法、存储介质 |
CN112039753A (zh) * | 2020-08-31 | 2020-12-04 | 北京百度网讯科技有限公司 | 消息打包与接收方法、装置、电子设备和介质 |
CN113242172A (zh) * | 2021-04-26 | 2021-08-10 | 福建天泉教育科技有限公司 | 一种消息的应答方法及系统 |
CN113515700A (zh) * | 2021-07-01 | 2021-10-19 | 深圳追一科技有限公司 | 信息推送方法、装置、电子设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1476181A (zh) * | 2003-07-14 | 2004-02-18 | 中国科学院计算技术研究所 | 一种分布式的卫星网络tcp性能加速协议格式和方法 |
CN102132515A (zh) * | 2008-08-20 | 2011-07-20 | 三星电子株式会社 | 无线通信系统中生成自动重发请求反馈消息的装置和方法 |
-
2012
- 2012-01-19 CN CN201210017771.2A patent/CN103220206B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1476181A (zh) * | 2003-07-14 | 2004-02-18 | 中国科学院计算技术研究所 | 一种分布式的卫星网络tcp性能加速协议格式和方法 |
CN102132515A (zh) * | 2008-08-20 | 2011-07-20 | 三星电子株式会社 | 无线通信系统中生成自动重发请求反馈消息的装置和方法 |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104683288B (zh) * | 2013-11-26 | 2018-09-28 | 腾讯科技(北京)有限公司 | 消息续传方法和装置 |
CN104683288A (zh) * | 2013-11-26 | 2015-06-03 | 腾讯科技(北京)有限公司 | 消息续传方法和装置 |
CN105450365A (zh) * | 2014-08-20 | 2016-03-30 | 北大方正集团有限公司 | 消息发送和消息接收装置及其方法和消息交互系统 |
CN104954446B (zh) * | 2015-05-28 | 2019-02-12 | 北京中亦安图科技股份有限公司 | 消息推送方法及系统 |
CN104954446A (zh) * | 2015-05-28 | 2015-09-30 | 北京中亦安图科技股份有限公司 | 消息推送方法及系统 |
CN105306348A (zh) * | 2015-11-10 | 2016-02-03 | 上海斐讯数据通信技术有限公司 | 群聊延漏消息的解决方法以及即时通讯工具 |
CN105487963A (zh) * | 2015-11-26 | 2016-04-13 | 小米科技有限责任公司 | 消息确认方法及装置 |
CN105487963B (zh) * | 2015-11-26 | 2018-04-06 | 小米科技有限责任公司 | 消息确认方法及装置 |
CN106921554B (zh) * | 2015-12-24 | 2020-09-29 | 北京新媒传信科技有限公司 | 消息传输方法及装置 |
CN106921554A (zh) * | 2015-12-24 | 2017-07-04 | 北京新媒传信科技有限公司 | 消息传输方法及装置 |
CN107040563B (zh) * | 2016-02-04 | 2021-01-19 | 阿里巴巴集团控股有限公司 | 异步服务处理方法及服务器 |
CN107040563A (zh) * | 2016-02-04 | 2017-08-11 | 阿里巴巴集团控股有限公司 | 异步服务处理方法及服务器 |
CN105812235B (zh) * | 2016-03-04 | 2020-05-29 | 百度在线网络技术(北京)有限公司 | 消息处理方法、装置及系统 |
CN105812235A (zh) * | 2016-03-04 | 2016-07-27 | 百度在线网络技术(北京)有限公司 | 消息处理方法、装置及系统 |
US11252121B2 (en) | 2016-03-23 | 2022-02-15 | Alibaba Group Holding Limited | Message sending method and terminal device |
WO2017162045A1 (zh) * | 2016-03-23 | 2017-09-28 | 阿里巴巴集团控股有限公司 | 一种消息的发送方法和终端设备 |
CN105956889A (zh) * | 2016-06-07 | 2016-09-21 | 乐视控股(北京)有限公司 | 广告监测方法、装置及系统 |
CN105978796A (zh) * | 2016-06-28 | 2016-09-28 | 乐视控股(北京)有限公司 | 基于不稳定移动网络的消息通信方法及系统 |
CN106331093A (zh) * | 2016-08-23 | 2017-01-11 | 惠州市拉维尼科技有限公司 | 数据发送方法 |
CN106331094A (zh) * | 2016-08-23 | 2017-01-11 | 惠州市拉维尼科技有限公司 | 转发方法 |
CN110602245A (zh) * | 2019-09-26 | 2019-12-20 | 福建天泉教育科技有限公司 | 提高应用软件吞吐量的方法、存储介质 |
CN110602245B (zh) * | 2019-09-26 | 2022-03-29 | 福建天泉教育科技有限公司 | 提高应用软件吞吐量的方法、存储介质 |
CN112039753A (zh) * | 2020-08-31 | 2020-12-04 | 北京百度网讯科技有限公司 | 消息打包与接收方法、装置、电子设备和介质 |
CN112039753B (zh) * | 2020-08-31 | 2024-08-20 | 北京百度网讯科技有限公司 | 消息打包与接收方法、装置、电子设备和介质 |
CN113242172A (zh) * | 2021-04-26 | 2021-08-10 | 福建天泉教育科技有限公司 | 一种消息的应答方法及系统 |
CN113242172B (zh) * | 2021-04-26 | 2023-02-28 | 福建天泉教育科技有限公司 | 一种消息的应答方法及系统 |
CN113515700A (zh) * | 2021-07-01 | 2021-10-19 | 深圳追一科技有限公司 | 信息推送方法、装置、电子设备及存储介质 |
CN113515700B (zh) * | 2021-07-01 | 2024-02-20 | 深圳追一科技有限公司 | 信息推送方法、装置、电子设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN103220206B (zh) | 2017-04-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103220206A (zh) | 一种消息发送方法、装置和一种消息接收方法、装置 | |
CN101867613B (zh) | 一种内容分发cdn子系统以及数据同步的方法 | |
CN104980450B (zh) | 一种消息传递方法和系统及消息处理设备 | |
CN103095746A (zh) | 一种通过微博向群用户发送消息的方法及装置 | |
CN1842063A (zh) | 一种即时通信方法 | |
CN101009516A (zh) | 一种进行数据同步的方法及系统 | |
CN108228363A (zh) | 一种消息发送方法及装置 | |
CN103167428B (zh) | 图片适配方法、手机报推送装置与系统 | |
CN101674318A (zh) | 一种向移动设备定时推送数据的方法 | |
CN104270302B (zh) | 在线订单的传送系统及传送方法 | |
CN101729593A (zh) | 一种上传和接收文件的方法、系统及装置 | |
CN113890895A (zh) | 消息推送方法和装置、存储介质及电子装置 | |
CN103532784A (zh) | 一种发送心跳消息的方法、系统、终端及网络设备 | |
CN103297453A (zh) | 实现即时通讯的方法、浏览器端和系统 | |
CN100433867C (zh) | 一种防止移动终端中个人数据丢失的方法及装置 | |
CN101106550A (zh) | 大尺寸消息的发送方法、接收方法及传输系统 | |
CN102917039A (zh) | 信息处理方法与系统 | |
CN104618432A (zh) | 一种事件发送与接收的处理方法和处理系统 | |
CN101895579A (zh) | 通讯录同步方法和系统 | |
CN102611641A (zh) | 采集即时通信记录进行汇总的方法及系统 | |
CN102624628A (zh) | 一种家庭网关及其实现数据包快速转发的方法 | |
CN105163171A (zh) | 一种机顶盒与移动终端之间的文件传输方法及系统 | |
CN102118709B (zh) | 提高彩信群发业务时格式转换效率的方法及系统 | |
CN101510872B (zh) | 远程用户拨号认证服务客户端、服务器、发送/接收方法 | |
CN103209213A (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 | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1183570 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: GR Ref document number: 1183570 Country of ref document: HK |