CN106357761A - 基于实时操作系统的分布式消息通信中间件实现软件系统 - Google Patents

Abstract

本发明提供了一种基于实时操作系统的分布式消息通信中间件实现软件系统，包括：链路层、通信过程控制层、管理层以及应用编程接口层，其中：所述链路层，用于实现物理地址寻址、数据的成帧、流量控制、数据的检错、数据的重发；所述通信过程控制层，采用添加新的通信过程控制协议的方式适应任意形式的底层传输；所述管理层，用于建立、维护或删除通信组，处理使用分布式消息通信中间件的数据传送服务过程中出现的错误和超时；所述应用编程接口层，用于提供编程接口，并通过调用编程接口实现消息传输。本发明实现一对多以及多对一的数据通信，数据通信效率不低于直接调用驱动时的80％，且易于扩充，在通信过程中能够自动选择链路。

Description

基于实时操作系统的分布式消息通信中间件实现软件系统

技术领域

本发明涉及分布式消息通信中间件领域，具体地，涉及一种基于实时操作系统的分布式消息通信中间件实现软件系统。

背景技术

随着现代水声技术的发展，对声呐信号处理的能力需求不断提高，一方面，为提高声呐性能而对声呐基阵空间增益的需求使得水声阵列的规模越来越大，由于先进的信号处理算法运算需求规模与阵列规模成2-3次方增加，导致运算需求急剧增加；另一方面，由于海洋环境具有高度的复杂特性，为了获取更加精确的参数，需要引入更加复杂的基于精细的水声物理模型的算法，使得信号处理规模进一步扩展。信号处理规模的扩展，使得一个问题的解决需要多个处理器的参与，从而加剧了程序的复杂度，为了使写出的程序一方面具备良好的移植性，另一方面为了让程序设计者把精力更多的放到算法设计上来而不用过多的关注底层通信。因此，提出了在实时操作系统上实现分布式消息通信中间件的要求。并对其功能作了如下的要求。

分布式消息通信中间件作为(以下简称IPC)用于任务间数据的搬移。对用户来说，IPC应屏蔽体系架构细节，比如，用户只管调用消息发送函数向对方端口发送消息即可，根本不需关心对方端口是在与自己不同的哪个节点上，只要相互通信的端口间存在物理链路(如以太网、rapidio、共享内存)即可。

IPC应具有以下功能：

1)底层链路支持广泛(如同时支持共享内存、rapidio、网络三种通信模式)；

2)支持大块数据以及短消息两种数据格式；

3)支持单发多收、多发单收、单发单收三种传输方式；

4)链路类型可指定也可自动选择，并且，要求IPC数据传输的性能不得低于直接调用驱动函数时的数据传输性能的80％。

目前，国内外已有相应的中间件软件，比如CWCEC公司的IPC，Enea的LINX，然而在具体的应用要求下，他们就显得功能不足，比如CWCEC公司的IPC和LINX就不具有一对多的通信功能。

CWCEC公司的IPC

相同点：传输效率高，支持多发一收通信模式，底层链路支持rapidio和共享内存。

不同点：无一发多收通信模式，底层链路不支持网络，且链路不能自动选择，无法跨机箱通信。

Enea的LINX

相同点：支持多种底层链路，且链路能够自动选择。

不同点：无一发多收和多发一收通信模式，传输效率低于80％。

MPI(消息传递接口)

相同点：mpi与本软件实现的功能类似。

不同点：无在reworks等实时操作系统上的开源实现，现有的开源实现如mpich支持Linux这样的通用操作系统。

另一款与本软件实现的功能类似的软件mpi(消息传递接口)，它其实是一个通用标准，其具体实现由具体的用户负责。相对于本软件mpi标准内容复杂，涉及的概念多，目前开源的实现如mpich也仅仅支持Linux这样的通用操作系统，并没有开源的在实时操作系统如reworks上的实现版本，本软件针对水声领域，结构简单、功能/性能满足水声应用。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种基于实时操作系统的分布式消息通信中间件实现软件系统。

根据本发明提供的基于实时操作系统的分布式消息通信中间件实现软件系统，包括：链路层、通信过程控制层、管理层以及应用编程接口层，其中：

所述链路层，用于实现物理地址寻址、数据的成帧、流量控制、数据的检错、数据的重发；

所述通信过程控制层，采用添加新的通信过程控制协议的方式适应任意形式的底层传输；

所述管理层，用于建立、维护或删除通信组，处理使用分布式消息通信中间件的数据传送服务过程中出现的错误和超时；

所述应用编程接口层，用于提供编程接口，并通过调用编程接口实现消息传输。

优选地，所述管理层包括：组管理模块、超时管理模块以及错误管理模块；

所述组管理模块，用于发现端口、构建通信组以及维护通信组；

所述超时管理模块，用于根据操作系统提供的定时器或设定的超时信号量执行等待操作；

所述错误管理模块，用于在分布式消息通信中间件出错时获取错误码，并根据错误码排查错误。

优选地，所述通信过程控制层包括：传输控制模块和消息队列服务模块；

所述传输控制模块，用于实现通信链路的自动选择，控制收发端的节奏，使收发端全对等，并对大块数据进行分片分次传输；其中：全对等是指对应用程序何时调用分布式消息通信中间件的发送函数或接收函数，以及先调用发送函数还是先调用接收函数均无限定；

所述消息队列服务模块，用于将消息队列里收到的数据分发给对应的端口或者分发给组管理，其中：消息队列用于传输控制过程的握手信息的收发和组管理过程中系统内同名端口间的信息交互。

优选地，所述链路层的通信链路包括：TCP、rapidio以及共享内存中的任一种媒介。

优选地，分布式消息通信中间件的接口按通信模式分为：一发多收模式、多发一收模式以及一发一收模式这三种模式；所述应用编程接口层按照每种通信模式的通信接口分为：开端口接口、发送接口、接收接口、关端口接口、错误管理接口以及分布式消息通信中间件的初始化接口。

优选地，

一发多收模式是指：将系统内的所有同名端口组成一发多收通信组，实现一发多收；

多发一收模式是指：将系统内的所有同名端口组成多发一收通信组，实现多发一收；

一发一收模式是指：将系统内的所有同名端口组成一发一收通信组，实现一发一收。

与现有技术相比，本发明具有如下的有益效果：

1、本发明提供的基于实时操作系统的分布式消息通信中间件实现软件系统实现一对多以及多对一的数据通信，数据通信效率不低于直接调用驱动时的80％。

2、本发明提供的基于实时操作系统的分布式消息通信中间件实现软件系统支持核级、片级以及机箱级的通信，底层链路支持共享内存、rapidio等多种方式且易于扩充。

3、本发明提供的基于实时操作系统的分布式消息通信中间件实现软件系统传输效率高，在通信过程中，能够自动选择链路。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为分布式消息通信中间件的四层软件结构示意图；

图2为分布式消息通信中间件的结构定义框图；

图3为本发明的收发流程图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

根据本发明提供的基于实时操作系统的分布式消息通信中间件实现软件系统，包括：链路层、通信过程控制层、管理层以及应用编程接口层。

分布式消息通信中间件通过“组”和“端口”的概念，实现了信号处理系统上的同名端口间的分布式消息通信。其软件结构基于如简化了的图1所示结构。

每一层与信号处理系统中的其它层的相关/无关性如表1所示。

表1软件层的无关性

链路层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。在这一层，数据的单位称为帧。分布式消息通信中间件的数据链路层可以是rapidio，共享内存或者甚至一个包传输协议(如TCP、UDP、SCTP等)。

通信过程控制层的任务主要有：(1)提供可靠的、有序的数据传输。通信过程控制层可以包含任何通信过程控制协议。当数据链路层是不可靠的，比如以太网或者有一些其他特性，通信过程控制层协议必须采用如流控制、丢包重传、节点监控等方法，通信过程控制层协议会变得复杂很多。而在可靠媒介上，比如共享内存或者RapidIO，通信过程控制层协议会十分简单。可通过添加新的通信过程控制协议，分布式消息通信中间件可以适用于任意底层传输。(2)负责数据的分发，能够将接收到的数据分发到正确的端口上去。(3)自动选择通信链路。

管理层的任务主要有：(1)负责建立、维护和删除通信组。(2)处理使用分布式消息通信中间件的数据传送服务过程中出现的错误和超时。管理层由一个通用的、独立于操作系统的协议模块和一个处理操作系统特定交互的操作系统适配层组成。

分布式消息通信中间件作为处于操作系统和应用软件中间的软件，应提供一套供应用层使用的编程接口，应用层通过调用这些接口就可以实现在信号处理系统中的消息传输。

分布式消息通信中间件的结构定义如图2所示，在具体实现的时候，按照层次化的实现思想，依次实现管理层、通信过程控制层。并提供编程接口给用户。

更进一步地，通过具体实施例对本发明做进一步地说明。

实施例：

如图2所示结构，按以下步骤分层实现：

步骤1：实现管理层，分布式消息通信中间件的管理层包括：组管理、超时管理以及错误管理；

组管理

组管理的任务主要有发现端口、构建通信组以及维护通信组三项，具体地，包括如下步骤：

步骤A1：发现端口，当创建好一个端口后，如果该端口是发送端口，则会向系统中发请求，寻找与端口名字相同的接收端口，具有相同名字的接收端口会回复一条响应，当发送端获知接收端的信息后，发送端会将接收端的信息存在其端口数据结构表中，从而建立了发送与接收之间的路由。如果对发出的请求一直没有响应，请求在一定的延时之后会继续发出，这个过程会一直重复直到收到回复或者超时。如果该端口是接收端口，则会将端口信息广播到网络中，如果在这之前已有发送端口打开，则会接收到广播信息，并以此建立路由或不理睬(该发送端口对发广播的接收端口不感兴趣)。

步骤A2：构建通信组，当系统中存在多个同名端口时，组管理的发现端口功能都能够发现它们，并将它们的信息存在发送端口的数据结构表中。

步骤A3：维护通信组，通信组的维护主要涉及两方面，一是动态添加发送端口数据结构表里存的接收端口的信息；如果系统内有新的同名接收端口被打开，组管理的发现端口功能会发现，同时会把端口信息加入到同名发送端口的数据结构表中。二是关闭连接；它发生在当发送或接收调用删除端口编程接口的时候，或发送或接收任务退出的时候，或发送或接收处理器奔溃的时候。关闭连接可分为两类，一类是协商关闭连接，当发送或接收调用删除端口编程接口时的关闭连接叫做协商关闭。如果是发送端调删除端口编程接口，发送端会等待所有发出的消息的确认信息都收到后，才关闭，因此，删除端口编程接口函数返回，并不表示端口已经关闭。如果是接收端调删除端口编程接口，接收端的输入队列里的所有消息都回复NAK。另一类是非协商关闭连接，主要发生在：(1)任务终止：在reworks系统里，该情况下端口会被正确的关闭。(2)处理器复位：底层驱动能够检测到。(3)处理器死锁：此时，发送端因为有传输控制而被阻塞，应用设计者需要解决这个问题。

超时管理

分布式消息通信中间件至少应在以下几个方面支持超时处理。1)当发送端调用了发送函数，但接收端还未调用接收函数，这时发送端应根据用户设定的等待值进行等待；2)接收端调用了接收函数，但发送端还未调发送函数，此时接收端应根据用户设定的等待值进行等待。3)在多任务下，如果打开的端口已经被一个任务占用，此时，如果另一个任务想用此端口，则这个想要使用的任务应根据用户设定的等待值进行等待。在以上三种情况下，如果超时仍未满足继续执行的条件，则分布式消息通信中间件应能作出相应的处理。

超时管理的功能是通过操作系统提供的定时器或带有超时功能的信号量等待接口实现的。

错误管理

分布式消息通信中间件应具备错误管理功能和方法，以方便用户调试，当分布式消息通信中间件在使用过程中出错，用户应能够获取错误码并能够根据错误码排查错误。

分布式消息通信中间件采用类似POSIX标准的做法，设置一个全局的变量，当发生错误时，就会给这个全局的变量赋值，同时提供获取错误信息的接口以供应用程序调用。

步骤2：实现通信过程控制层，通信过程控制层主要提供传输控制和消息队列服务两项功能。

传输控制

传输控制提供了可靠的、有序的数据传输以及自动选择通信链路的功能。传输控制的设计因通信链路的不同而不同。当通信链路是TCP的时候是不需要传输控制的。当通信链路是rapidio和共享内存时，传输控制的作用有：(1)控制收发端的节奏，使收发端全对等。全对等是指对应用程序何时调用分布式消息通信中间件的发送函数或接收函数以及先调用发送函数还是先调用接收函数都没有要求。(2)对大块数据进行分片分次传输。因具体的通信链路一次能传输的数据量是有限的，因此需要对大块进行分片，使每次传输的大小不超过实际通信链路能够传输的大小。当通信链路是以太网等不可靠的链路时，传输控制就需要好好的设计。

当通信链路是TCP、rapidio以及共享内存这样的可靠的媒介的时候，控制收发端的节奏可以通过在数据收发过程中加入握手来实现的，此时的收发流程如图3所示：

当发送端调用发送接口时，首先会向接收端发送允许发送请求，如果此时接收端未调用接收接口，则发送接口会阻塞直到超时；如果此时接收端调用了接收接口，则接收端会回复可以发送信息给发送端，这时，发送端发送数据。最后的数据传输完成是指发送端发送完数据后告知接收端数据已发送完成。

消息队列服务

消息队列服务用于将消息队列里收到的数据分发给对应的端口或者分发给组管理。消息队列用于传输控制过程的握手信息的收发和组管理过程中系统内同名端口间的信息交互。

步骤3：实现应用编程接口层，分布式消息通信中间件的接口设计应遵循以下要求：

1)接口种类应尽可能的少；

2)接口使用应尽可能的简单；

3)接口应能体现出IPC的功能特性；

4)传入接口的参数不能包含与某个具体系统相关的参数，如不应有rapidio的id号，网络的IP地址等与某个具体的系统相关的参数。

分布式消息通信中间件的接口按通信模式可划分为一发多收、多发一收以及一发一收三类，每种通信模式的通信接口可划分为开端口接口、发送接口、接收接口、关端口接口。另外，还应提供错误管理接口以及分布式消息通信中间件的初始化接口。

初始化接口

分布式消息通信中间件的初始化接口的功能包括分配资源，初始化守护任务以及初始化全局数据结构。对该接口的要求有：(1)应用在调用初始化接口之后可正常的使用分布式消息通信中间件的其它函数，而在未调用初始化接口的情况下不能使用分布式消息通信中间件的其它函数。(2)应支持用户重复调用初始化函数，此时应设置错误码。

初始化编程接口见表2。

表2分布式消息通信中间件的初始化接口列表

一发多收接口功能要求：应能将系统内的所有同名端口组成一发多收通信组，实现一发多收。一发多收编程接口见表3。

表3分布式消息通信中间件的初始化接口列表

多发一收接口功能要求：应能将系统内的所有同名端口组成多发一收通信组，实现多发一收。多发一收编程接口见表4。

表4分布式消息通信中间件的初始化接口列表

一发一收接口功能要求：应能将系统内的所有同名端口组成一发一收通信组，实现一发一收。一发一收编程接口见表5。

表5分布式消息通信中间件的初始化接口列表

错误管理接口功能要求：能够获取错误信息。错误管理编程接口见表6。

表6分布式消息通信中间件的初始化接口列表

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (6)

1.一种基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，包括：链路层、通信过程控制层、管理层以及应用编程接口层，其中：

所述链路层，用于实现物理地址寻址、数据的成帧、流量控制、数据的检错、数据的重发；

所述通信过程控制层，采用添加新的通信过程控制协议的方式适应任意形式的底层传输；

所述管理层，用于建立、维护或删除通信组，处理使用分布式消息通信中间件的数据传送服务过程中出现的错误和超时；

所述应用编程接口层，用于提供编程接口，并通过调用编程接口实现消息传输。

2.根据权利要求1所述的基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，所述管理层包括：组管理模块、超时管理模块以及错误管理模块；

所述组管理模块，用于发现端口、构建通信组以及维护通信组；

所述超时管理模块，用于根据操作系统提供的定时器或设定的超时信号量执行等待操作；

所述错误管理模块，用于在分布式消息通信中间件出错时获取错误码，并根据错误码排查错误。

3.根据权利要求1所述的基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，所述通信过程控制层包括：传输控制模块和消息队列服务模块；

所述传输控制模块，用于实现通信链路的自动选择，控制收发端的节奏，使收发端全对等，并对大块数据进行分片分次传输；其中：全对等是指对应用程序何时调用分布式消息通信中间件的发送函数或接收函数，以及先调用发送函数还是先调用接收函数均无限定；

所述消息队列服务模块，用于将消息队列里收到的数据分发给对应的端口或者分发给组管理，其中：消息队列用于传输控制过程的握手信息的收发和组管理过程中系统内同名端口间的信息交互。

4.根据权利要求1所述的基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，所述链路层的通信链路包括：TCP、rapidio以及共享内存中的任一种媒介。

5.根据权利要求1所述的基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，分布式消息通信中间件的接口按通信模式分为：一发多收模式、多发一收模式以及一发一收模式这三种模式；所述应用编程接口层按照每种通信模式的通信接口分为：开端口接口、发送接口、接收接口、关端口接口、错误管理接口以及分布式消息通信中间件的初始化接口。

6.根据权利要求5所述的基于实时操作系统的分布式消息通信中间件实现软件系统，其特征在于，

一发多收模式是指：将系统内的所有同名端口组成一发多收通信组，实现一发多收；

多发一收模式是指：将系统内的所有同名端口组成多发一收通信组，实现多发一收；

一发一收模式是指：将系统内的所有同名端口组成一发一收通信组，实现一发一收。