一种分布式仿真通信消息处理方法及装置

技术领域

本申请涉及分布式消息处理技术领域，尤其是涉及一种分布式仿真通信消息处理方法及装置。

背景技术

模拟训练通过利用计算机仿真技术，构建装备的动力、行为仿真模型，可实现真实虚拟三维环境下的人人、人机（计算机生成兵力，CGF）战术对抗训练。而且，模拟训练不受实际场景、天气等条件限制，在训练过程中可以随时对环境条件、装备状态进行干预控制，是实装训练的有效互补手段，目前在相关行业已经成为日常训练的一种重要形式。

分布式模拟训练过程中，仿真引擎负责构建CGF模型，并根据想定任务对CGF模型进行状态更新。训练人员通过客户端登陆仿真系统，接收仿真引擎推送的信息，并进行实时态势接收和场景更新。根据当前推演过程时刻的战场态势，进行指挥控制、情报处理、装备操作等任务执行。通常情况下，仿真的实体规模达到几百甚至成千，且因为人在环训练参与，要求仿真实时推进，仿真步长通常在几十毫秒。

目前的仿真引擎平台通常利用了计算机多核心多线程的优势，客户端场景更新则充分利用了GPU的快速并行处理能力，均可满足仿真实时推演的性能要求。然而，在客户端接收并处理仿真引擎通过消息中间件发送的场景实体更新消息处理过程中，因仿真实体数量多、消息解析慢等因素，容易引起客户端消息解析阻塞，造成场景更新不及时甚至程序崩溃等问题。

发明内容

有鉴于此，本申请提供了一种分布式仿真通信消息处理方法及装置，以解决上述技术问题。

第一方面，本申请实施例提供了一种分布式仿真通信消息处理方法，包括：

接收服务器发送的实体状态消息，所述实体状态消息包括状态信息数据包，所述状态信息数据包包括每个仿真时刻的整个场景内所有更新的实体的状态数据；

利用处理线程对实体状态消息的状态信息数据包进行解析，将解析得到的实体状态消息的时间戳和各实体的状态数据放入实体包，将实体包放入处理线程对应的线程资源池映射字典的实体包队列；

对实体包队列的所有实体包按照时间戳进行排序，读取排序后的第一个实体包数据；

从第一个实体包数据中获取各实体的状态数据，根据各实体的状态数据对场景中的实体进行渲染。

进一步，所述方法还包括：

创建线程池，所述线程池包括预设数量的处理线程；

创建线程资源池映射字典，为线程池中的处理线程生成线程ID号；

为线程资源池映射字典创建一个实体包队列，用于存储实体包，所述实体包的数据结构包括：线程ID号、时间戳和实体数据缓存队列；所述实体数据缓存队列用于存储各实体的状态数据，各实体的状态数据包括：实体ID号，位置、姿态和生存状态，其中，生存状态表示实体是否已被击毁。

进一步，利用处理线程对实体状态消息的状态信息数据包进行解析前包括：

判断线程池当前活跃线程的个数是否已达到预设数量，若为否，则创建新线程作为处理线程，并利用线程资源池映射字典为处理线程生成线程ID号；否则，从线程池内选取一个空闲线程作为处理线程。

进一步，利用处理线程对实体状态消息的状态信息数据包进行解析，将解析后的实体状态消息时间戳和各实体的状态数据放入实体包；包括：

创建一个实体包；

将处理线程的线程ID号赋值给实体包的线程ID号；

从实体状态消息的状态信息数据包中获取实体状态消息的时间戳，将该时间戳赋值给实体包的时间戳；

从实体状态消息的状态信息数据包获取各实体的状态数据，将所有实体的状态数据放入实体包的实体数据缓存队列。

进一步，从实体状态消息的状态信息数据包获取各实体的状态数据，将所有实体的状态数据放入实体包的实体数据缓存队列；包括：

步骤S1：根据通信协议获得单个实体的状态数据的数据结构大小，作为单个实体数据大小；

步骤S2：以实体状态消息的状态信息数据包的读取标识位置为起始位置，读取单个实体数据大小的数据，作为单个实体的状态数据；

步骤S3：根据通信协议，判断单个实体信息数据中的实体类型是否为实体；若为是，则将该单个实体的状态数据放入实体包的实体数据缓存队列，进入步骤S4；否则终止当前处理，并提示错误信息，进入步骤S4；

步骤S4：判断状态信息数据包是否读取完毕，若为是，则结束处理；否则将实体状态消息的状态信息数据包的读取标识位置进行偏移，偏移量为单个实体数据大小，返回步骤S2。

进一步，所述方法还包括：随机生成各实体的状态数据，对场景进行初始化。

进一步，根据各实体的状态数据对场景中的实体进行渲染，包括：

对于每个实体，根据实体ID号判断所述实体是否在当前场景中，若为否，将所述实体添加到场景内，并根据实体的状态数据设置实体的位置和姿态；否则，根据实体生存状态判断实体是否已被击毁，若为是，则将实体从场景中移除；否则，根据实体的状态数据对场景内实体的位置和姿态进行更新；

根据各实体的位置和姿态对场景中的实体进行渲染。

第二方面，本申请实施例提供了一种分布式仿真通信消息处理装置，包括：

接收单元，接收服务器发送的实体状态消息，所述实体状态消息包括状态信息数据包，所述状态信息数据包包括每个仿真时刻中整个场景内所有更新实体的状态数据；

解析单元，利用处理线程对消息的状态信息数据包进行解析，将解析后的各实体的状态数据放入处理线程对应的线程资源池映射字典的实体包队列；

排序单元，用于对实体包队列的所有实体包数据按照时间戳进行排序，读取排序后的第一个实体包数据；

渲染单元，用于从第一个实体包数据中获取各实体的状态数据，根据各实体的状态数据对场景中的实体进行渲染。

第三方面，本申请实施例提供了一种电子设备，包括：存储器、处理器和存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本申请实施例的分布式仿真通信消息处理方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令被处理器执行时实现本申请实施例的分布式仿真通信消息处理方法。

本申请可以有效解决仿真场景实体数量较多时引起的客户端消息解析阻塞，造成场景更新不及时甚至程序崩溃等问题；提高实体消息响应速度和场景渲染效率。

附图说明

为了更清楚地说明本申请具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的整体技术方案的示意图；

图2为本申请实施例提供分布式仿真通信消息处理方法的流程图；

图3为本申请实施例提供的消息接收处理流程示意图；

图4为本申请实施例提供的分布式仿真通信消息处理装置的功能结构图；

图5为本申请实施例提供的电子设备的结构图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

首先对本申请实施例的设计思想进行简单介绍。

针对分布式仿真通信过程中客户端消息处理不及时造成的阻塞问题，本申请提出了分布式仿真通信消息处理方法，基于线程池后台处理的技术体制，在接收到仿真引擎推送的消息后通过后台线程池进行多线程消息快速处理，实现了客户端的消息接收快速实时处理。同时，针对消息并行解析时序保持问题，通过采用实体消息整体封包+时间戳排序技术，解决了消息解析多线程处理过程中的实体时间戳排序问题。

如图1所示，本申请的技术方案包括三部分：

第一部分：消息接收触发后台线程处理：

为解决态势推演过程中，以仿真实体为单位进行通信时，会引起网络通信数据发送和接收过于频繁而导致网络问题，因此以态势整体为单位进行实体状态消息发送，即将每个仿真推演时间步中整个场景内所有更新的实体打包成一个状态信息包进行发送。

创建了线程资源池映射字典数据结构，用于对线程池中线程的标识；创建了实体包数据队列数据结构，主要包括实体数据缓存队列、对应线程ID、时间戳等信息，用于解析本地消息包队列中的实体信息，并与线程资源池映射字典进行映射。

对消息接收处理类进行实例化创建，并对本地信息包队列等类变量进行初始化。

客户端在接收到消息后，触发对线程池线程资源进行判断，创建新线程或采用已有线程进行处理。

判断仿真运行是否结束，若结束则退出运行，释放消息处理类占用资源；若未结束，则继续运行。

第二部分：多线程后台解析

实例化线程池资源相关管理类，并根据计算机计算资源情况，分配线程池可管理的最大线程数。为每个线程分配用于消息处理的数据缓存队列资源。

判断线程池当前活跃线程是否已达到最大线程数，如果没有达到，则创建新线程。如果达到，则挑选线程池内空闲线程。假设该线程为Threadn,则并将线程对应线程ID和对应的数据缓存队列加入线程资源池映射字典。

线程Threadn对接收信息数据进行实体解析，并根据线程资源池映射字典数据结构m_dic的映射关系，将解析后的数据存入线程Threadn对应的实体包数据队列

第三部分：场景更新。

场景初始化：主要对内存中的计算机生成兵力实体进行释放，此外进行相关界面面板资源的管理和显示。

场景实体更新：首先对所有实体包队列的实体包按照时间戳进行排序，排序算法此处采用了快速排序算法。

读取排序后的实体包数据队列的第一个实体包，并根据实体当前的状态信息进行场景更新。程序运行结束时，主要对相关资源进行释放。

本申请采用上述技术方案，可有效解决仿真场景实体数量较多时引起的客户端消息解析阻塞，造成场景更新不及时甚至程序崩溃等问题。主要利用多线程并行处理能力，解决分布式仿真运行过程中客户端快速处理仿真引擎推送的消息实体信息，实现对消息信息实体的及时处理，避免因客户端消息处理慢而引起的消息阻塞问题。

在介绍了本申请实施例的应用场景和设计思想之后，下面对本申请实施例提供的技术方案进行说明。

如图2所示，本申请实施例提供了一种分布式仿真通信消息处理方法，包括以下骤：

步骤101：接收服务器发送的实体状态消息，所述实体状态消息包括状态信息数据包，所述状态信息数据包包括每个仿真时刻的整个场景内所有更新的实体的状态数据；

步骤102：利用处理线程对实体状态消息的状态信息数据包进行解析，将解析得到的实体状态消息的时间戳和各实体的状态数据放入实体包，将实体包放入处理线程对应的线程资源池映射字典的实体包队列；

在本实施例中，为了实现多线程处理，如图3所示，首先创建一个线程池，所述线程池包括预设数量的处理线程，例如：Thread0、Thread1、…、Threadn；然后创建线程资源池映射字典，为线程池中的处理线程生成线程ID号：thread0、thread1、…、threadn；再为线程资源池映射字典创建一个实体包队列，用于存储实体包，所述实体包的数据结构包括：线程ID号、时间戳（例如：tstamp0）和实体数据缓存队列(data1、data2、data3…、dataN)；所述实体数据缓存队列用于存储各实体的状态数据，各实体的状态数据包括：实体ID号，位置、姿态和生存状态，其中，生存状态表示实体是否已被击毁。

判断线程池当前活跃线程的个数是否已达到预设数量，若为否，则创建新线程作为处理线程，并利用线程资源池映射字典为处理线程生成线程ID号；否则，从线程池内选取一个空闲线程作为处理线程。

具体的，利用处理线程对实体状态消息的状态信息数据包进行解析，将解析后的实体状态消息时间戳和各实体的状态数据放入实体包；包括：

创建一个实体包；

将处理线程的线程ID号赋值给实体包的线程ID号；

从实体状态消息的状态信息数据包中获取实体状态消息的时间戳，将该时间戳赋值给实体包的时间戳；

从实体状态消息的状态信息数据包获取各实体的状态数据，将所有实体的状态数据放入实体包的实体数据缓存队列：

从实体状态消息的状态信息数据包获取各实体的状态数据，将所有实体的状态数据放入实体包的实体数据缓存队列；包括：

步骤S1：根据通信协议获得单个实体的状态数据的数据结构大小，作为单个实体数据大小；

步骤S2：以实体状态消息的状态信息数据包的读取标识位置为起始位置，读取单个实体数据大小的数据，作为单个实体的状态数据；

步骤S3：根据通信协议，判断单个实体信息数据中的实体类型是否为实体；若为是，则将该单个实体的状态数据放入实体包的实体数据缓存队列，进入步骤S4；否则终止当前处理，并提示错误信息，进入步骤S4；

步骤S4：判断状态信息数据包是否读取完毕，若为是，则结束处理；否则将实体状态消息的状态信息数据包的读取标识位置进行偏移，偏移量为单个实体数据大小，返回步骤S2。

步骤103：对实体包队列的所有实体包按照时间戳进行排序，读取排序后的第一个实体包数据；

由于实体包队列的实体包是由不同的处理线程得到的，因此当读取实体包队列中的实体包时，需要对实体包队列中的所有实体包按照时间戳进行排序。

步骤104：从第一个实体包数据中获取各实体的状态数据，根据各实体的状态数据对场景中的实体进行渲染。

首先随机生成各实体的状态数据，对场景进行初始化。

当开始接收服务器发送的状态信息数据包后，从第一个实体包数据中获取各实体的状态数据，对于每个实体，根据实体ID号判断所述实体是否在当前场景中，若为否，将所述实体添加到场景内，并根据实体的状态数据设置实体的位置和姿态；否则，根据实体生存状态判断实体是否已被击毁，若为是，则将实体从场景中移除；否则，根据实体的状态数据对场景内实体的位置和姿态进行更新；根据各实体的位置和姿态对场景中的实体进行渲染。

基于上述实施例，本申请实施例提供了一种分布式仿真通信消息处理装置，参阅图4所示，本申请实施例提供的分布式仿真通信消息处理装置200至少包括：

接收单元201，接收服务器发送的实体状态消息，所述实体状态消息包括状态信息数据包，所述状态信息数据包包括每个仿真时刻中整个场景内所有更新实体的状态数据；

解析单元202，利用处理线程对消息的状态信息数据包进行解析，将解析后的各实体的状态数据放入处理线程对应的线程资源池映射字典的实体包队列；

排序单元203，用于对实体包队列的所有实体包数据按照时间戳进行排序，读取排序后的第一个实体包数据；

渲染单元204，用于从第一个实体包数据中获取各实体的状态数据，根据各实体的状态数据对场景中的实体进行渲染。

需要说明的是，本申请实施例提供的分布式仿真通信消息处理装置200解决技术问题的原理与本申请实施例提供的分布式仿真通信消息处理方法相似，因此，本申请实施例提供的分布式仿真通信消息处理装置200的实施可以参见本申请实施例提供的分布式仿真通信消息处理方法的实施，重复之处不再赘述。

如图5所示，本申请实施例提供的电子设备300至少包括：处理器301、存储器302和存储在存储器302上并可在处理器301上运行的计算机程序，处理器301执行计算机程序时实现本申请实施例提供的分布式仿真通信消息处理方法。

本申请实施例提供的电子设备300还可以包括连接不同组件（包括处理器301和存储器302）的总线303。其中，总线303表示几类总线结构中的一种或多种，包括存储器总线、外围总线、局域总线等。

存储器302可以包括易失性存储器形式的可读介质，例如随机存储器（RandomAccess Memory，RAM）3021和/或高速缓存存储器3022，还可以进一步包括只读存储器（ReadOnly Memory，ROM）3023。

存储器302还可以包括具有一组（至少一个）程序模块3025的程序工具3024，程序模块3025包括但不限于：操作子系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备300也可以与一个或多个外部设备304（例如键盘、遥控器等）通信，还可以与一个或者多个使得用户能与电子设备300交互的设备通信（例如手机、电脑等），和/或，与使得电子设备300与一个或多个其它电子设备300进行通信的任何设备（例如路由器、调制解调器等）通信。这种通信可以通过输入/输出（Input /Output，I/O）接口305进行。并且，电子设备300还可以通过网络适配器306与一个或者多个网络（例如局域网（Local AreaNetwork，LAN），广域网（Wide Area Network，WAN）和/或公共网络，例如因特网）通信。如图5所示，网络适配器306通过总线303与电子设备300的其它模块通信。应当理解，尽管图5中未示出，可以结合电子设备300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、磁盘阵列（Redundant Arrays of IndependentDisks，RAID）子系统、磁带驱动器以及数据备份存储子系统等。

需要说明的是，图5所示的电子设备300仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，该计算机指令被处理器执行时实现本申请实施例提供的分布式仿真通信消息处理方法。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。