CN115567472A - 消息传输方法、装置、服务端及存储介质 - Google Patents

Abstract

本申请提供一种消息传输方法、装置、服务端及存储介质。该方法包括：接收第一客户端上传的至少一个上行消息；根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；根据所述第二客户端的标识生成所述第二客户端对应的下行消息；存储所述第二客户端的至少一个下行消息，并对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息；将所述携带编号的下行消息下发至所述第二客户端；若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。本申请的方法，可以提高消息传输的准确性，从而能够适用于对数据准确性要求较高的使用场景。

Description

消息传输方法、装置、服务端及存储介质

技术领域

本申请涉及消息传输技术，尤其涉及一种消息传输方法、装置、服务端及存储介质。

背景技术

随着消息传输技术的发展，例如在实时数据交换过程中，为了防止实时数据在交换过程中，出现数据丢失从而影响数据交换效率，或者在物联网设备与物联网平台之间传输数据时避免数据出现丢失。因此，出现了消息传输方法。

目前，现有的消息传输方法，大多采用隧道模式，交换实时数据的双方先借助服务器建立数据通道，之后双方直接进行实时数据交换。还有借助数据队列进行实时数据交换。

然而，隧道模式和数据队列方式下，由于更注重数据达到的即时性，因此通常会为了更快速地将数据从第一客户端通过服务端转发到第二客户端，会牺牲一定的准确率来换取消息传输的即时性，因此，不适于某些对数据准确性要求较高的使用场景。

发明内容

本申请提供一种消息传输方法、装置、服务端及存储介质，用以解决现有技术中，难以适用于对数据准确性要求较高的使用场景的技术问题。

第一方面，本申请提供一种消息传输方法，包括：

接收第一客户端上传的至少一个上行消息；

根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；

根据所述第二客户端的标识生成所述第二客户端对应的下行消息；

对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息；

将所述携带编号的下行消息下发至所述第二客户端；

若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

第二方面，本申请提供一种消息传输装置，包括：

上行消息获取模块，用于接收第一客户端上传的至少一个上行消息；

客户端确定模块，用于根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；

下行消息生成模块，用于根据所述第二客户端的标识生成所述第二客户端对应的下行消息；

下行消息发送模块，用于对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息；

下行消息发送模块，用于将所述携带编号的下行消息下发至所述第二客户端；

下行消息重发模块，用于若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

第三方面，本申请提供一种服务端，包括：处理器，以及与所述处理器通信连接的存储器及收发器；

所述存储器存储计算机执行指令；所述收发器，用于收发数据；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如第一方面所述的方法。

本申请提供的消息传输方法、装置、服务端及存储介质，通过接收第一客户端上传的至少一个上行消息；根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；根据所述第二客户端的标识生成所述第二客户端对应的下行消息；存储所述第二客户端的至少一个下行消息，并对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息；将所述携带编号的下行消息下发至所述第二客户端；若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。由于在获得第二客户端的至少一个携带编号的下行消息之后，先存储再下发至第二客户端，当第二客户端存在消息丢失时，即可根据存储的携带编号的下行消息，将丢失的消息发送给第二客户端，从而使得第二客户端即使存在消息丢失，也能够找回丢失的消息，提高消息传输的准确性，从而适用于对数据准确性要求较高的使用场景。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为实现本申请实施例的消息传输方法的一种应用场景图；

图2为本申请一实施例的实现消息传输方法的流程示意图；

图3为本申请另一实施例的实现消息传输方法的流程示意图；

图4为本申请实现消息传输方法的结构示意图；

图5为用来实现消息传输方法中的服务端的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为了清楚理解本申请的技术方案，首先对现有技术的方案进行详细介绍。

现有的消息传输方法，大多采用隧道模式，交换实时数据的双方先借助服务器建立数据通道，之后双方直接进行实时数据交换。还有借助数据队列进行实时数据交换。然而，隧道模式和数据队列方式下，由于更注重数据达到的即时性，因此通常会为了更快速地将数据从第一客户端通过服务端转发到第二客户端，会牺牲一定的准确率来换取消息传输的即时性，因此，不适于某些对数据准确性要求较高的使用场景。

所以在面对现有技术的技术问题时，发明人通过创造性的研究后发现，为了能够适用于对数据准确性要求较高的使用场景。因此，在消息传输过程中尽可能地提高消息传输的准确性。在具体设置时，服务端接收第一客户端上传的至少一个上行消息时，确定第二客户端以及生成第二客户端对应的下行消息之后，对至少一个下行消息进行编号，获得第二客户端的至少一个携带编号的下行消息。在获得第二客户端的至少一个携带编号的下行消息之后，先存储再下发至第二客户端，当第二客户端存在消息丢失时，即可根据存储的携带编号的下行消息，将丢失的消息发送给第二客户端，从而使得第二客户端即使存在消息丢失，也能够找回丢失的消息，提高消息传输的准确性，从而适用于对数据准确性要求较高的使用场景。

如图1所示，本申请实施例提供的消息传输方法的应用场景，在该应用场景中对应的网络架构中包括第一客户端10、服务端20和第二客户端30，第一客户端10和第二客户端30分别和服务端20进行通信连接。第一客户端10向服务端20先上传至少一个上行消息，服务端20接收到至少一个上行消息时，根据上行消息确定至少一个第二客户端30并根据第二客户端30的标识生成第二客户端30对应的下行消息。之后，服务端20再对至少一个下行消息编号以获得至少一个携带编号的下行消息，并进行存储。存储之后再下发至第二客户端30，当第二客户端30存在消息丢失时，则从存储的携带编号的下行消息中，将丢失的消息发送给第二客户端30。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2是本申请一实施例提供的消息传输方法，如图2所示，本实施例提供的消息传输方法的执行主体是服务端。则本实施例提供的消息传输方法包括以下步骤：

步骤101，接收第一客户端上传的至少一个上行消息。

其中，第一客户端是指发送消息的客户端，可应用于在线聊天场景，在该场景中第一客户端对应为发送实时消息的客户端，例如用户A通过用户终端A给用户B的终端发送消息，此处的用户终端A即第一客户端。第一客户端还可应用于物联网场景，在该场景中，第一客户端对应为物联网终端设备，所发送的消息是第一客户端监测的数据。例如，第一客户端可以是居民用水表(或电表)，则第一客户端监测的数据包括用水情况(或用电情况)。

上行消息是指第一客户端发送至服务端的消息。在进行消息传输时，第一客户端上传的上行消息可能是一个，也可能是多个。

对于第一客户端上传至少一个上行消息时，若上行消息的数量为多个，则第一客户端逐个上传至服务端，第一客户端每上传成功一个上行消息时，服务端先存储，然后再返回该上行消息的确认收到消息，确认收到消息中包括该上行消息的tag标签。若服务端存储失败，则向第一客户端发送上传失败消息，上传失败消息中包括该上行消息的tag标签，可用于指示第一客户端重新发送该上行消息。或者，若第一客户端在发送完一个上行消息后的设定时长内，未接收到服务端返回的该上行消息的确认收到消息，则第一客户端确定上传失败，重新将该上行消息上传至服务端。通过这样的反馈机制，从而可以保证第一客户端传输消息至服务端时，不会存在消息漏传的情况。此外，第一客户端在成功上传每一个上行消息之后，服务端会对各上行消息依次进行编号，从而获得携带编号的上行消息。上行消息。相应地，第一客户端每上传成功一个上行消息时，服务端先存储，然后再返回该上行消息的确认收到消息，确认收到消息中包括该上行消息的tag标签和该上行消息的编号。

步骤102，根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端。

其中，第二客户端是指接收消息的客户端，可应用于在线聊天场景，在该场景中第二客户端对应为接收实时消息的客户端，例如用户B通过用户终端B接收用户A的终端发送的消息，此处的用户终端B即第二客户端。第二客户端还可应用于物联网场景，在该场景中，第二客户端对应为物联网平台，所接收的消息是第一客户端监测的数据。例如，第一客户端监测的数据包括用水情况(或用电情况)，则第二客户端接收的数据包括用水情况(或用电情况)。

上行消息中携带了与确定第二客户端相关的信息，因此，服务端根据上行消息能够确定至少一个第二客户端。上行消息中携带了与确定第二客户端相关的信息，可以理解为第一客户端上传上行消息至服务端时，服务端根据上行消息可以确定第一客户端所要发送的第二客户端。

步骤103，根据所述第二客户端的标识生成所述第二客户端对应的下行消息。

其中，当第二客户端的数量为多个时，可以根据各第二客户端的标识生成对应的下行消息，从而服务端可以确保各第二客户端均收到下行消息。当第二客户端的数量为一个时，根据第二客户端的标识生成对应的下行消息，从而服务端可以确保将下行消息准确发送至该第二客户端中。

下行消息是指第二客户端从服务端接收的消息。下行消息和上行消息中传输的消息内容是相同的，下行消息和上行消息的区别在于封装消息内容的协议头发生了变化。

可选的，在生成第二客户端对应的下行消息之前，先将上行消息进行复制，得到复制的上行消息，并删除该上行消息。若有多个上行消息，则是每复制成功获得一个复制的上行消息，即删除对应的上行消息。当所有上行消息复制成功时，则删除各上行消息。在获得复制的上行消息之后，再根据第二客户端的标识生成第二客户端对应的下行消息。

步骤104，对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息。

其中，携带编号的下行消息是具有编号的下行消息，相对于原始的下行消息只增加了编号信息。

为了防止服务端传输消息给第二客户端的过程中，在出现消息丢失时，难以确定丢失的消息的情况，服务端在获得第一客户端发送的至少一个下行消息时，即对至少一个下行消息进行编号，获得第二客户端的至少一个携带编号的下行消息，因此在出现消息丢失时，根据携带编号的下行消息能够快速确定丢失的消息。在进行编号时，针对每个第二客户端的编号可以是连续的，也可以是不连续的。对于不连续的编号，可以预先确定各编号前后的顺序。

进一步地，为了防止消息传输过程中出现丢失的情况，服务端在对下行消息进行编号之后，还进行存储，存储是为了防止第二客户端未成功接收到服务端的下行消息时，能够再从服务端获取，从而有利于防止消息传输过程中出现丢失的情况，可以提高消息传输的准确性。

步骤105，将所述携带编号的下行消息下发至所述第二客户端。

其中，若第二客户端只有一个，携带编号的下行消息具有多个，则将各携带编号的下行消息依次发送给该第二客户端。若第二客户端只有一个，携带编号的下行消息仅有一个，则将该携带编号的下行消息发送至第二客户端。若第二客户端有多个，携带编号的下行消息具有多个，则将各第二客户端对应的多个携带编号的下行消息分别依次发送给各第二客户端。若第二客户端有多个，携带编号的下行消息仅有一个，则将该携带编号的下行消息分别发送至各第二客户端中。

步骤106，若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

其中，当第二客户端丢失消息时，服务端可以通过第二客户端主动上报或者基于第二客户端返回的信息，确定第二客户端是否丢失消息。若确定第二客户端存在消息丢失，则可以基于原先存储的携带编号的下行消息，将丢失的消息发送给第二客户端。

本申请中，接收第一客户端上传的至少一个上行消息；根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；根据所述第二客户端的标识生成所述第二客户端对应的下行消息；存储所述第二客户端的至少一个下行消息，并对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息；将所述携带编号的下行消息下发至所述第二客户端；若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。由于在获得第二客户端的至少一个携带编号的下行消息之后，先存储再下发至第二客户端，当第二客户端存在消息丢失时，即可根据存储的携带编号的下行消息，将丢失的消息发送给第二客户端，从而使得第二客户端即使存在消息丢失，也能够找回丢失的消息，提高消息传输的准确性，从而适用于对数据准确性要求较高的使用场景。

作为一种可选实施方式，如图3所示，本实施例中，上行消息中包括：上行协议头；步骤102，包括以下步骤：

步骤201，判断所述上行协议头中是否具有至少一个终端的标识、至少一个用户的标识或者至少一个社群的标识中的任意一种标识。

其中，上行协议头是指上行消息中的协议头，协议头即数据传输协议中的协议头。上行协议头中可能具有终端的标识、用户的标识或者社群的标识，当第一客户端的发送对象是具体的第二客户端时，上行协议头中具有终端的标识。当第一客户端的发送对象是用户时，上行协议头中具有用户的标识。当第一客户端的发送对象是社群时，上行协议头中具有社群的标识。

步骤202，若确定具有至少一个终端的标识，则将所述至少一个终端，确定为所述第一客户端待转发数据的第二客户端。

其中，若确定上行协议头中具有至少一个终端的标识，则将该至少一个终端，确定为第二客户端。若确定具有一个终端的标识，则将该终端确定为第二客户端。若确定具有多个终端的标识，则将该多个终端确定为各第二客户端。

步骤203，若确定具有至少一个用户的标识，则将所述至少一个用户对应的终端，确定为所述第一客户端待转发数据的第二客户端。

其中，若确定具有一个用户的标识，则该用户对应的终端可以是一个，也可以是多个，多个的情况是该用户可能登录了多个终端，因此上行协议头中具有该用户登录的所有终端。用户对应的终端，即该用户当前在线时所登录的各个终端。若确定具有一个用户的标识，则将该用户对应的终端确定为第二客户端。若确定具有多个用户的标识，则将多个用户分别对应的终端确定为第二客户端。

步骤204，若确定具有至少一个社群的标识，则将所述至少一个社群对应的多个用户的终端，确定为所述第一客户端待转发数据的第二客户端。

其中，社群是指由前述的用户所组织构成的群体。例如，用户为企业员工时，社群是指企业。若确定具有一个社群的标识，则将该社群对应的终端，确定为第二客户端。此处，社群对应的终端是指该社群中当前在线的所有用户所登录的各个终端。

若确定具有多个社群的标识，则将该多个社群对应的终端，确定为各第二客户端。

将至少一个社群对应的多个用户的终端，确定为各第二客户端的使用场景，例如企业***升级或企业公告等。

本实施例中，通过判断所述上行协议头中是否具有至少一个终端的标识、至少一个用户的标识或者至少一个社群的标识中的任意一种标识；若确定具有至少一个终端的标识，则将所述至少一个终端，确定为所述第一客户端待转发数据的第二客户端；若确定具有至少一个用户的标识，则将所述至少一个用户对应的终端，确定为所述第一客户端待转发数据的第二客户端；若确定具有至少一个社群的标识，则将所述至少一个社群对应的多个用户的终端，确定为所述第一客户端待转发数据的第二客户端。由于在确定至少一个第二客户端时，是根据上行协议头中携带的标识类别确定的，因此，可以提高确定第二客户端的准确性。

作为一种可选实施方式，本实施例中，上行消息还包括消息体；上行消息还包括消息体；步骤103，包括以下步骤：

步骤301，根据所述第二客户端的地址，在所述上行协议头中添加对应的第二客户端的地址，以获得下行协议头。

其中，第二客户端的地址，是指第二客户端的IP地址(Internet ProtocolAddress)。服务端在上行协议头中添加第二客户端的地址，添加后即获得下行协议头。服务端只有在确定下行消息的发送地址时，才可以准确地发送下行消息。

步骤302，根据所述下行协议头和所述消息体生成所述第二客户端对应的下行消息。

其中，下行消息包括下行协议头和消息体，相比于上行消息，下行消息仅变化了下行协议头的部分内容，这部分内容即前述的添加了第二客户端的地址。

在上行协议头中添加第二客户端的地址，从而服务端能够将消息体准确的传输至第二客户端中。

本实施例中，根据所述第二客户端的地址，在所述上行协议头中添加对应的第二客户端的地址，以获得下行协议头；根据所述下行协议头和所述消息体生成所述第二客户端对应的下行消息。由于下行消息中的下行协议头中携带了第二客户端的地址，因此可以确保服务端将下行消息传输给第二客户端时，准确地发送至第二客户端中。

作为一种可选实施方式，本实施例中，步骤104，具体包括：分别对至少一个同属于一个第二客户端的下行消息依次由小到大进行编号，以获得第二客户端的至少一个携带编号的下行消息。

其中，若第二客户端的数量为多个，服务端在将下行消息传输给各第二客户端时，是对同属于一个第二客户端的下行消息依次按照从小到大的顺序进行编号，从而获得各第二客户端的至少一个携带编号的下行消息。若第二客户端的数量为一个，服务端在将下行消息传输给该第二客户端时，也是对属于该第二客户端的下行消息依次按照从小到大的顺序进行编号，从而获得该第二客户端的至少一个携带编号的下行消息。在下行消息的数量为一个的情况下，该下行消息仍然可以进行编号，例如为最小编号“1”。

本实施例中，分别对至少一个同属于一个第二客户端的下行消息依次由小到大进行编号，以获得第二客户端的至少一个携带编号的下行消息。由于是对至少一个同属于一个第二客户端的下行消息由小到大进行编号，从而使在第二客户端有多个的情况下，服务端在传输下行消息给各第二客户端时，方便判断哪些第二客户端存在消息丢失，有利于提高消息传输的准确性。

作为一种可选实施方式，本实施例中，步骤105之后，还包括以下步骤：

步骤401，判断是否接收到第二客户端的发送的至少一个携带编号的下行消息对应的下行消息成功接收消息。

其中，若携带编号的下行消息的数量为多个，服务端在传输携带编号的下行消息至第二客户端时，是将各携带编号的下行消息按照编号从小到大逐个地传输给第二客户端。第二客户端每成功接收到一个携带编号的下行消息时，则向服务端返回一个下行消息成功接收消息，下行消息成功接收消息中包括下行消息的编号，以告知服务端其成功接收到该下行消息。

可选地，若在下行消息传输过程中，第二客户端未成功接收某一个下行消息，则第二客户端可以不向服务端返回任何消息。

步骤402，若接收到第二客户端的发送的某携带编号的下行消息对应的下行消息成功接收消息，则删除该携带编号的下行消息。

其中，若接收到第二客户端发送的某携带编号的下行消息对应的下行消息成功接收消息，表明该携带编号的下行消息已经被第二客户端成功接收，此时服务端可以删除该携带编号的下行消息。

本实施例中，判断是否接收到第二客户端的发送的至少一个携带编号的下行消息对应的下行消息成功接收消息；若接收到第二客户端的发送的某携带编号的下行消息对应的下行消息成功接收消息，则删除该携带编号的下行消息。由于服务端在确定第二客户端成功接收到某携带编号的下行消息时，便将该携带编号的下行消息删除，因此，有利于减少服务端的数据缓存冗余。

作为一种可选实施方式，本实施例中，判断第二客户端是否存在消息丢失，包括：若在发出每个携带编号的下行消息的预设时长内，未接收到所述第二客户端对于某个携带编号的下行消息对应的下行消息成功接收消息，则确定所述第二客户端存在消息丢失。

其中，服务端在判断第二客户端是否存在消息丢失时，是依据预设时长内是否接收到第二客户端发送的下行消息成功接收消息确定的。

相应地，步骤106，具体包括：若确定第二客户端存在消息丢失，则将未接收到所述第二客户端发送的下行消息成功接收消息对应的携带编号的下行消息确定为丢失的消息，并将所述丢失的消息发送给所述第二客户端。

本实施例中，若在发出每个携带编号的下行消息的预设时长内，未接收到所述第二客户端对于某个携带编号的下行消息对应的下行消息成功接收消息，则确定所述第二客户端存在消息丢失。由于在确定消息是否丢失时，是服务端依据预设时长内是否接收到第二客户端的下行消息成功接收消息确定的，因此，可以保证判断第二客户端是否存在消息丢失的准确性。

作为一种可选实施方式，本实施例中，在步骤101之前，还包括以下步骤：

步骤501，若监测到所述第一客户端请求与所述服务端建立通信连接，则获取所述第一客户端的注册信息。

步骤502，根据所述第一客户端的注册信息，对所述第一客户端进行注册。

其中，第一客户端注册时，需要提交_cid_、_uid_、_dev_、_appname_、_appver_等信息，这些信息以协议头的形式进行封装。

步骤503，若注册成功，则生成所述第一客户端的会话标识。

其中，会话标识即_sid_。

步骤504，存储所述第一客户端的会话标识，并下发至所述第一客户端。

作为一种可选实施方式，本实施例中，在所述步骤101之前，还包括：

步骤601，接收所述第一客户端发送的数据上传指令，所述数据上传指令包括所述第一客户端的会话标识。

步骤602，校验所述数据上传指令中的第一客户端的会话标识，与预先存储的第一客户端的会话标识是否一致。

步骤603，若确定一致，则执行步骤101。

图4是本申请一实施例提供的消息传输装置的结构示意图，如图4所示，本实施例提供的消息传输装置4040位于服务端中，则本实施例提供的消息传输装置4040，包括：上行消息获取模块41，客户端确定模块42，下行消息生成模块43，下行消息编号模块44，下行消息发送模块45和下行消息重发模块46，其中：

上行消息获取模块41，用于接收第一客户端上传的至少一个上行消息；

客户端确定模块42，用于根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；

下行消息生成模块43，用于根据所述第二客户端的标识生成所述第二客户端对应的下行消息；

下行消息编号模块44，用于对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息；

下行消息发送模块45，用于将所述携带编号的下行消息下发至所述第二客户端；

下行消息重发模块46，用于若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

可选地，所述上行消息中包括：上行协议头；客户端确定模块42，具体用于：判断所述上行协议头中是否具有至少一个终端的标识、至少一个用户的标识或者至少一个社群的标识中的任意一种标识；若确定具有至少一个终端的标识，则将所述至少一个终端，确定为所述第一客户端待转发数据的第二客户端；若确定具有至少一个用户的标识，则将所述至少一个用户对应的终端，确定为所述第一客户端待转发数据的第二客户端；若确定具有至少一个社群的标识，则将所述至少一个社群对应的多个用户的终端，确定为所述第一客户端待转发数据的第二客户端。

可选地，所述上行消息还包括消息体；所述第二客户端的标识包括地址；下行消息生成模块43，具体用于：根据所述第二客户端的地址，在所述上行协议头中添加对应的第二客户端的地址，以获得下行协议头；根据所述下行协议头和所述消息体生成所述第二客户端对应的下行消息。

可选地，下行消息编号模块44，具体用于：分别对至少一个同属于一个第二客户端的下行消息依次由小到大进行编号，以获得第二客户端的至少一个携带编号的下行消息。

可选地，消息传输装置40，还包括下行消息删除模块，用于：判断是否接收到第二客户端的发送的至少一个携带编号的下行消息对应的下行消息成功接收消息；若接收到第二客户端的发送的某携带编号的下行消息对应的下行消息成功接收消息，则删除该携带编号的下行消息。

可选地，消息传输装置40，还包括消息丢失确定模块，用于：若在发出每个携带编号的下行消息的预设时长内，未接收到所述第二客户端对于某个携带编号的下行消息对应的下行消息成功接收消息，则确定所述第二客户端存在消息丢失。

可选地，下行消息重发模块46，具体用于：若确定第二客户端存在消息丢失，则将未接收到所述第二客户端发送的下行消息成功接收消息对应的携带编号的下行消息确定为丢失的消息，并将所述丢失的消息发送给所述第二客户端。

图5是根据一示例性实施例示出的一种服务端的框图，该设备可以是如图5所示，服务端，包括：存储器51，处理器52以及收发器54；存储器51用于存储处理器可执行指令的存储器；收发器54用于收发数据；处理器52用于运行计算机程序或指令，以实现如上任意一个实施例提供的消息传输方法。

其中，存储器51，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器51可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

其中，处理器52可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本公开实施例的一个或多个集成电路。

可选的，在具体实现上，如果存储器51、处理器52和收发器54独立实现，则存储器51、处理器52和收发器54可以通过总线53相互连接并完成相互间的通信。总线53可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线53、外部设备互连(Peripheral Component，简称为PCI)总线53或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，简称为EISA)总线53等。总线53可以分为地址总线53、数据总线53、控制总线53等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线53或一种类型的总线53。

可选的，在具体实现上，如果存储器51、处理器52和和收发器54集成在一块芯片上实现，则存储器51、处理器52和和收发器54可以通过内部接口完成相同间的通信。

一种非临时性计算机可读存储介质，当该存储介质中的指令由服务端的处理器执行时，使得服务端能够执行上述服务端的消息传输方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (10)

1.一种消息传输方法，应用于服务端，其特征在于，所述方法包括：

接收第一客户端上传的至少一个上行消息；

根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；

根据所述第二客户端的标识生成所述第二客户端对应的下行消息；

对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息；

将所述携带编号的下行消息下发至所述第二客户端；

若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

2.根据权利要求1所述的方法，其特征在于，所述上行消息中包括：上行协议头；

所述根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端，包括：

判断所述上行协议头中是否具有至少一个终端的标识、至少一个用户的标识或者至少一个社群的标识中的任意一种标识；

若确定具有至少一个终端的标识，则将所述至少一个终端，确定为所述第一客户端待转发数据的第二客户端；

若确定具有至少一个用户的标识，则将所述至少一个用户对应的终端，确定为所述第一客户端待转发数据的第二客户端；

若确定具有至少一个社群的标识，则将所述至少一个社群对应的多个用户的终端，确定为所述第一客户端待转发数据的第二客户端。

3.根据权利要求2所述的方法，其特征在于，所述上行消息还包括消息体；所述第二客户端的标识包括地址；所述根据第二客户端的标识生成所述第二客户端对应的下行消息，包括：

根据所述第二客户端的地址，在所述上行协议头中添加对应的第二客户端的地址，以获得下行协议头；

根据所述下行协议头和所述消息体生成所述第二客户端对应的下行消息。

4.根据权利要求1所述的方法，其特征在于，所述对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，包括：

分别对至少一个同属于一个第二客户端的下行消息依次由小到大进行编号，以获得第二客户端的至少一个携带编号的下行消息。

5.根据权利要求1所述的方法，其特征在于，在将所述携带编号的下行消息下发至所述第二客户端之后，所述方法还包括：

判断是否接收到第二客户端的发送的至少一个携带编号的下行消息对应的下行消息成功接收消息；

若接收到第二客户端的发送的某携带编号的下行消息对应的下行消息成功接收消息，则删除该携带编号的下行消息。

6.根据权利要求5所述的方法，其特征在于，判断第二客户端是否存在消息丢失，包括：

若在发出每个携带编号的下行消息的预设时长内，未接收到所述第二客户端对于某个携带编号的下行消息对应的下行消息成功接收消息，则确定所述第二客户端存在消息丢失；

若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端，包括：

若确定第二客户端存在消息丢失，则将未接收到所述第二客户端发送的下行消息成功接收消息对应的携带编号的下行消息确定为丢失的消息，并将所述丢失的消息发送给所述第二客户端。

7.一种消息传输装置，其特征在于，所述装置包括：

上行消息获取模块，用于接收第一客户端上传的至少一个上行消息；

客户端确定模块，用于根据所述上行消息，确定所述第一客户端待转发数据的至少一个第二客户端；

下行消息生成模块，用于根据所述第二客户端的标识生成所述第二客户端对应的下行消息；

下行消息编号模块，用于对所至少一个下行消息进行编号，以获得所述第二客户端的至少一个携带编号的下行消息，并存储所述第二客户端的至少一个下行消息；

下行消息发送模块，用于将所述携带编号的下行消息下发至所述第二客户端；

下行消息重发模块，用于若确定第二客户端存在消息丢失，则将丢失的消息发送给所述第二客户端。

8.一种服务端，包括：处理器，以及与所述处理器通信连接的存储器及收发器；

所述存储器存储计算机执行指令；

所述收发器，用于收发数据；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-6中任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-6任一项所述的方法。

10.一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现权利要求1-6中任一项所述的方法。

Images