一种DDS分布式应用仿真的方法和系统

一种dds分布式应用仿真的方法和系统
技术领域
1.本发明涉及网络仿真领域，特别是涉及一种dds分布式应用仿真的方法和系统。


背景技术：

2.在分布式系统的网络中，节点之间可以共享数据，并与不同的节点进行交互，这些节点之间的依赖关系通常会在分布式网络中创建一个复杂的体系。在常规的通信模型中，发布/订阅模型可以将分布式系统在时间、空间和控制流上的依赖关系完全解耦合，降低分布式系统的复杂性。但传统的发布/订阅系统中，数据分发服务和分发要求都由每个系统独立的实现，大量重复劳动和资源浪费造成效率低下，相关实现的质量因无统一的规范也良莠不齐，实现彼此之间的互通也因此变得困难和费时。建立在发布/订阅的数据传输基础上的数据分发服务(data distribution service，简写为dds)规范，充分考虑到分布式系统的高扩展性和高度动态性，可以在一定的程度上将分布式系统中各子系统完全解耦合，大大满足了分布式系统对实时性和灵活性的需求，并且其多样的qos策略也可以满足分布式系统中生产者和消费者对服务质量的不同需求。
3.dds规范在分布式系统中的应用是大势所趋，但直接在大型分布式系统搭建dds进行研究成本太大，而网络仿真技术可以迅速地创建起模型并进行良好的预测。因此，寻找一款能够基于dds对分布式系统进行仿真的平台，从而完成dds在分布式系统中的应用研究成为当下迫切的需求。
4.目前大型网络仿真平台如qualnet、exata、openet等，其平台构建的模型节点本身并不具备基于dds进行信息交互的能力的问题。以上平台搭建的网络都是基于虚拟网络协议栈进行通信，而基于ace和tao通信的dd s是以物理网络协议栈进行通信，故上述平台无法进行dds交互仿真。
5.鉴于此，如何克服现有技术所存在的缺陷，解决目前大型网络仿真平台无法进行dds交互仿真的现象，是本技术领域待解决的问题。


技术实现要素：

6.针对现有技术的以上缺陷或改进需求，本发明解决了目前大型网络仿真平台无法进行dds交互仿真的问题。
7.本发明实施例采用如下技术方案：
8.第一方面，本发明提供了一种dds分布式应用仿真的方法，具体为：根据需仿真的网络拓扑，创建相应数量的基于封装dds功能镜像的docker 容器作为主机节点，创建相应数量的ovs交换机作为虚拟交换机，并建立相应的网络拓扑，通过dds发布和订阅实现主机节点之间基于dds的数据交互；完成控制器和虚拟交换机之间的网络连接，网络连接的数据传输通过openflow协议实现；控制器实现二层交换机转发功能和ip组播功能，发现主机节点和虚拟交换机组成的网络拓扑，跟踪学习网络中的mac和ip 地址，以及主机的位置和链路状态，并控制虚拟交换机完成对网络包进行处理。
9.优选的，创建相应数量的基于dds的docker容器作为主机节点，具体包括：根据网络拓扑中的主机数量，创建相应数量的基于封装dds功能镜像的docker容器作为主机节点；将主机节点通过docker容器端口接入系统，使主机节点具有dds通信功能。
10.优选的，通过dds发布和订阅实现主机节点之间基于dds的数据交互，当主机节点具有发布者功能时，具体包括：创建并初始化域参与者，创建发布者；注册数据类型并创建对应的topic，创建数据写入者并配置qos 策略；根据传入的配置参数进行数据发布，发布完成后释放相关资源。
11.优选的，创建相应数量的基于封装dds功能镜像的docker容器作为主机节点，当主机节点具有订阅者功能时，具体包括：创建并初始化域参与者，创建订阅者；注册数据类型并创建对应的topic，创建数据读取者和对应的监听器，并配置qos策略；设置环形缓冲区，当订阅者订阅到数据后，放入环形缓冲区进行数据缓冲。
12.优选的，创建相应数量的ovs交换机作为虚拟交换机，具体包括：根据网络拓扑中的主机数量，创建相应数量的ovs交换机，其中有且仅有一个虚拟交换机作为查询者，其余虚拟交换机作为窥探者；基于ovs接口实现虚拟交换机之间的连接，使用ovs和docker的通信端口实现交换机和主机节点的连接。
13.优选的，完成控制器和虚拟交换机之间的网络连接，具体包括：使用o vs控制命令将虚拟交换机与控制器连接，并进行网络的互ping操作，以检测网络之间的连通性，在互ping的同时控制器通过ovs接口获取网络拓扑的信息；若网络已连通，进行后续的dds交互通信仿真。
14.优选的，控制虚拟交换机完成对igmp协议包进行处理，具体包括：虚拟交换机中的查询者根据自身的组播转发表，按照发送周期泛洪发送普遍组查询报文，并根据接收到的igmp报文，按照更新周期对组播转发表和对应端口的流表进行更新；虚拟交换机中的窥探者解析收到的igmp报文类型，根据不同类型分别进行报文处理，根据接收报文的端口学习通向查询者的端口信息，更新自身的组播转发表和查询者端口信息表。
15.优选的，根据不同类型分别进行报文处理，具体包括：当报文为查询报文时，窥探者重置组播转发表中端口状态并对查询报文进行泛洪，根据后续的报文反馈对组播转发表和对应端口的流表进行更新，窥探者根据报文的端口信息更新查询者端口信息表；当报文为成员报告报文时，查询者和窥探者根据报文信息更新组播转发表和对应端口的流表，窥探者将报文由通往查询者的端口发出；当报文为离组报文时，窥探者将报文由通往查询者的端口发出，查询者根据报文信息更新组播转发表和对应端口的流表。
16.优选的，建立相应的网络拓扑，还包括：
17.基于stp协议去除网络拓扑中的环路。
18.另一方面，本发明提供了一种dds分布式应用仿真的系统，包括应用层、控制层和数据层，具体的：数据层包括分布式系统业务中所有网元节点，节点之间基于dds进行信息交互，数据层通过北向接口与应用层进行数据交互；控制层具有二层交换机转发功能和ip组播功能，用于对数据层中的网络节点进行拓扑发现，并实现地址协议解析，控制层通过南向接口与数据层中的虚拟交换机节点连接，以完成第一方面中提供的dds分布式应用仿真的方法。
19.与现有技术相比，本发明实施例的有益效果在于：以sdn作为基础架构搭建仿真平
台，使得网络仿真拓扑可以自定义搭建，网络数据转发所需要的功能可以通过控制器灵活实现；采用docker容器作为仿真节点，使得分布式系统的业务可以根据需要灵活部署，dds中间件可以根据需求自定义选择，能够支持dds交互仿真，对dds系统服务质量以及性能等方面进行有效灵活的验证。
附图说明
20.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1为本发明实施例提供的一种dds分布式应用仿真的方法流程图；
22.图2为本发明实施例使用的网络拓扑实例示意图；
23.图3为本发明实施例可用的功能模块整体框架示意图；
24.图4为本发明实施例提供的另一种dds分布式应用仿真的方法流程图；
25.图5为本发明实施例使用的发布者和订阅者数据交互时序示意图；
26.图6为本发明实施例提供的另一种dds分布式应用仿真的方法流程图；
27.图7为本发明实施例中查询者和窥探者各自的处理逻辑示意图；
28.图8为本发明实施例中发送普遍组查询报文模块处理流程示意图；
29.图9为本发明实施例使用的查询者和窥探者的组播转发表结构示意图；
30.图10为本发明实施例中查询者包处理模块处理流程示意图；
31.图11为本发明实施例中窥探者包处理模块处理流程示意图；
32.图12为本发明实施例使用的窥探者的组播转发表结构示意图；
33.图13为本实施例提供的一种dds分布式应用仿真的系统整体框架示意图；
34.图14为本实施例提供的一种dds分布式应用仿真的系统逻辑描述示意图；
35.图15为本发明实施例中使用网桥连接两个docker容器进行通信的过程示意图。
具体实施方式
36.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
37.本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。
38.此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。
39.实施例1：
40.针对当前dds在实际大型分布式系统中部署验证成本高、且无法灵活的对系统网络进行控制、调度的问题，本实施例提供了一种以软件定义网络(soft definition network，简写为sdn)为基础架构搭建基于dds通信的仿真方案。sdn是网络虚拟化的一种实现方式，其核心技术openflow 通过将网络设备的控制面与数据面分离开来，从而实现了网
络流量的灵活控制，使网络变得更加智能，为核心网络及应用的创新提供了良好的平台。
41.使用本实施例提供的仿真方案，可以按照不同分布式系统的业务要求，基于容器化和虚拟化技术构建基于sdn网络的仿真环境。然后对分布式系统进行仿真建模。最后基于此分布式系统模型进行dds中间件的设计，从而实现dds在仿真模型中的信息交互，解决在大型分布式系统中无法基于d ds对系统服务质量以及性能等方面进行有效、灵活验证的问题。
42.如图1所示，本发明实施例提供的dds分布式应用仿真的方法，具体步骤如下：
43.步骤101：根据需仿真的网络拓扑，创建相应数量的基于封装dds功能镜像的docker容器作为主机节点，创建相应数量的ovs交换机作为虚拟交换机，并建立相应的网络拓扑，通过dds发布和订阅实现主机节点之间基于dds的数据交互。
44.本实施例中，以图2所示的一个k＝9的分布式系统的拓扑图为例进行说明，k表示拓扑节点数。图2中包含9个主机节点(host1-host9)，以及5台开放虚拟交换标准(openvswitch，简写为ovs)虚拟交换机，每个节点都基于自己打包的dds镜像的docker容器创建作为单独的节点。dock er容器都是基于镜像创建的，将dds功能封装成镜像后，每个容器基于此镜像进行创建，则每个容器都将具有dds功能。
45.本实施例中，对应网络拓扑中的9个主机节点，根据网络拓扑中的主机数量，创建相应数量的基于封装dds功能镜像的docker容器作为主机节点，本实施例中可以创建9个docker容器设置为主机节点，使用docker 容器对网络中的主机节点进行仿真，再将主机节点通过docker容器端口接入系统，使主机节点具有dds通信功能。在实际使用中，也可以创建比实际主机节点数更多的主机节点，例如创建10个docker容器作为主机节点，以便于扩展。在实际实施中，为了使主机节点支持dds数据传输，需要自行制作具有dds功能的镜像，操作为启动一个基本的linux容器，在此容器中设置环境变量，安装和编译dds，在此容器中运行dds示例成功后，使用dockercompose命令生成具有dds功能的镜像，主机节点基于此镜像生成则可具备dds通信功能。
46.进一步的，可以在dds的订阅端节点使用环形缓冲区技术进行数据缓存实现数据接收端的数据缓存功能，以模拟真实网络环境中设备缓冲区的使用情况。具体的，在具有dds订阅者功能的节点设置环形缓冲区，当订阅者订阅到数据后，放入环形缓冲区进行数据缓冲。当环形缓冲区已满后，丢弃数据，以模拟真实的缓冲区满时丢包的状态。
47.同样的，对应网络拓扑中的5台交换机，创建5个虚拟交换机。为了使虚拟交换机和主机节点间能够正常通信，将带有特定南向接口协议、拓扑发现以及地址解析协议功能的网络控制器与拓扑中的各个虚拟交换机连接，并通过网络控制器分别给网络中的各个虚拟交换机配置响应的流表，用户实现数据的转发。为了使主机节点和虚拟交换机支持dds的动态发现机制，使网络中的发布者和订阅者可以发现彼此，同时为了支持多对一的业务，还要为其添加ip组播功能，通过ip组播提高dds仿真网络的扩展性和灵活性。具体的，网络中的数据转发和dds通信所依赖的组播功能可以使用opendaylight控制器实现，对opendaylight进行二次开发，使虚拟交换机具有二层交换机的转发功能和ip组播功能。
48.建立主机节点和虚拟交换机后，还需要依据具体的网络拓扑，通过ov s网桥实现交换机与交换机、交换机与主机节点的docker容器之间的连接。本实施例使用的网络结构中，网络中不需要路由器，转发所需要的功能都可以通过控制器实现，路由器和交换机已无
区别。具体的，主机节点之间可以通过normal port进行数据交互，虚拟交换机之间以及虚拟交换机和主机节点之间可以通过patch port进行数据交互。
49.进一步的，由于真实网络环境中为了避免网络拓扑中的环路造成转发错误，会对环路进行识别和处理。本实施例中，为了尽可能模拟真实的网络运行情况，对网络拓扑中的连接关系进行仿真时，也可以基于生成树协议(spanning tree protocol，简写为stp)去除网络拓扑中的环路。
50.步骤102：完成控制器和虚拟交换机之间的网络连接，网络连接的数据传输通过openflow协议实现。
51.在仿真模拟中，需要通过控制器对仿真网络的参数和运行状态进行控制，并获取仿真运行的结果。本实施例提供的方法中，依照真实的网络拓扑，将控制器与虚拟交换机进行连接，通过openflow协议下发流表对交换机的数据转发进行控制。具体的，可以使用opendaylight(odl)控制器，生成opendaylight项目骨架，基于骨架进行二次开发，使得控制器具有二层交换机转发功能和ip组播功能；同时，将网络中所有虚拟交换机机协议设置为openflow1.3并与控制器相连，控制器得以通过openflow1.3协议下发流表对虚拟交换机进行控制。
52.本实施例提供的方法中，dds的实时发布订阅(real-time publish-s ubscribe，简写为rtps)发现机制和一对多业务信息传输是基于ip组播实现的，此外数据包转发必须基于交换机的二层转发功能，因此必须使控制器具有基本的二层交换机转发功能和ip组播功能。具体的，可以使用mav en工具生成碳(carbon)版本的opendaylight项目骨架，再根据实际的仿真需要编程实现具体功能模块。
53.步骤103：控制器实现二层交换机转发功能和ip组播功能，发现主机节点和虚拟交换机组成的网络拓扑，跟踪学习网络中的mac和ip地址，以及主机的位置和链路状态，并控制虚拟交换机完成对网络包进行处理。
54.经过步骤101和步骤102，完成网络拓扑结构的仿真后，即可开始进行网络实际运行情况的仿真。
55.首先进入控制器bin目录使用./karaf启动opendaylight控制器，经过互ping操作后控制器会获取当前的网络拓扑。获取网络拓扑后，检查网络拓扑与需求是否一致，以保证仿真系统与实际网络环境的运行情况一致。具体的，可以通过对网络中的所有主机执行ping操作，检测组网网络之间的连通性，在互ping的同时控制器会学习到网络拓扑；通过对仿真节点执行基于dds的数据收发操作，检测仿真平台基于dds传输的功能。
56.为了完整实现网络通信中的各项功能，可以使用如图3所示的整体框架完成通信和控制功能。整体框架分为初始化、网络包处理、arp协议包处理、地址跟踪学习、主机跟踪学习、消除环路和internet组管理协议(in ternet group management protocol，简写为igmp)包处理七部分。初始化模块进行删除交换机所有流表等操作，网络包处理模块进行网络包的解码并发布对应的notification，arp协议包处理模块为对arp协议包进行处理，地址跟踪学习模块学习网络中的mac和ip地址，主机跟踪学习模块学习网络中主机的位置和链路状态，消除环路模块基于stp协议去除网络中的环路，igmp协议处理模块处理igmp协议报文。通过上述模块的协同配合，即可完成仿真系统的控制和通信。
57.在实际实施过程中，控制器的二层交换机转发功能和ip组播功能可以通过二次开
发进行实现。虚拟交换机处理的网络包可以为igmp协议包，也可以为其他网络包。
58.经过本实施例中提供的步骤101-步骤103后，依照需仿真的网络拓扑建立起了节点、网络连接和dds通信功能的仿真模拟系统，并通过控制器对系统进行控制和状态获取，简单快速的实现了dds分布式应用的仿真。
59.由于dds为发布订阅模式，因此主机节点也需要添加订阅者和发布者的功能。具体的步骤101中通过dds发布和订阅实现主机节点之间基于dd s的数据交互，当主机节点为发布者时，需要进行相关初始化设置：创建并初始化域参与者，创建发布者和订阅者，注册数据类型并创建对应的topi c，创建数据写入者并配置qos策略，创建数据读取者和对应的监听器，并配置qos策略；根据传入的配置参数进行数据发布，发布完成后释放相关资源。
60.如图4所示，可以使用以下步骤完成主机节点的创建。
61.步骤201：通过启动代码时传入的argv、argc对参数进行配置。例如 qos配置、发包数量、发包频率等。
62.步骤202：创建并初始化域参与者。
63.步骤203：创建发布者。发布者用于对数据的发布。
64.步骤204：创建订阅者。对于发布端而言订阅者接收控制信息对消息发布进行控制。
65.步骤205：注册数据类型并创建对应的topic。
66.步骤206：创建数据写入者并配置qos策略。
67.步骤207：创建数据读取者和对应的监听器，并配置qos策略。
68.步骤208：根据传入的配置参数进行数据发布。
69.步骤209：发布完成后释放相关资源。
70.通过步骤201-步骤209，可以完成发布者和订阅者的创建和初始化，实现dds的发布和订阅功能。具体实施场景中，可以使用如图5的时序完成发布者和订阅者之间的数据交互。
71.进一步的，如图6所示，订阅者可以通过以下步骤接收订阅的数据。
72.步骤301：如果订阅到有效数据，则判断环形缓冲区状态是否已满。若是，转步骤302；若否，转步骤303。
73.步骤302：丢弃该数据。
74.步骤303：零拷贝获取数据并放入环形缓冲区等待主程序进行读取。
75.通过步骤301-步骤303，可以完成订阅者的数据接收。本实施例中，在dds中间件设计的基础上添加环形缓冲区，提高了dds订阅者接收信息的性能。
76.本实施例中，通过对控制器进行二次开发，编程实现igmp协议包处理模块，通过openflow协议下发流表来控制交换机对igmp协议的网络包转发，以完成ip组播的通信功能。因此，步骤101中，创建相应数量的ovs 交换机作为虚拟交换机时，还需要对查询者和窥探者的角色进行设置。根据网络拓扑中的主机数量，创建相应数量的ovs交换机，其中有且仅有一个虚拟交换机作为查询者，其余虚拟交换机作为窥探者，以便于控制器对所有虚拟交换机进行统一管理和数据交互。具体的，使用命令ovs-vsctl add-br创建基于openflow1.3协议的ovs交换机，更改交换机的datapath id，设定datapathid为1的为查询者，整个网络拓扑中有且仅有一个查询者。并在此基础上，基于ovs接口实现虚拟交换机之
间的连接，使用ovs 和docker的通信端口实现交换机和主机节点的连接。具体的，基于ovs-v sctl add-port和ovs-vsctl set interface实现交换机与交换机的连接。首先使用命令add-port在交换机上创建端口，然后使用set interface命令设置端口类型为patch，最后设置对端端口。经过上述设置和连接后，即可使用ovs-docker add-port命令实现交换机和主机节点或路由器节点的连接，实现数据包在虚拟交换机上的交换和转发。
77.在仿真过程中，控制器需要获取仿真网络的网络拓扑，以及各节点和链路的网络状态，将其作为仿真结果呈现给用户。因此，步骤102中，还需要完成控制器和虚拟交换机之间的网络连接。具体的，使用ovs控制命令将虚拟交换机与控制器连接，例如使用ovs-vsctl set-controller命令将交换机与控制器相连，并进行网络的互ping操作，通过网络设备间互相发送ping命令检测网络之间的连通性。在互ping的同时控制器通过ovs 接口获取网络拓扑的信息，并通过控制器的用户界面观察网络拓扑是否创建成功，以及当前的网络状态。若网络已连通，才进行后续的dds交互通信仿真。
78.在实际实施场景中，可以参考以下具体实施方式完成控制器对网络拓扑和网络状态的控制和获取，以下实施方式中的具体架构和参数可以根据实际需要进行设置，或在不冲突的情况下与其它现有技术相结合。
79.结合odl控制器特性，将igmp协议包处理模块设计分为查询者模块和窥探者模块两部分，查询者和窥探者共同维护着网络的组播转发表和组成员管理，查询者和窥探者各自的处理逻辑如图7所示。
80.控制器监听opendaylight-inventory数据库的数据变化事件，openda ylight-inventory存放所有与控制器连接交换机节点。通过ovs-vsctl可以设置交换机的datapathid，在控制器中映射为节点id，将节点id为1 的交换机的角色设置为查询者，网络中查询者仅有一个，将其他交换机节点角色设置为窥探者，查询者会启动发送普遍组查询报文模块线程。如果o penflowplugin模块接收到了igmp协议报文，则根据交换机的角色不同进行相应的包处理模块，角色为查询者进入查询者包处理模块，角色为窥探者则进入窥探者包处理模块。
81.虚拟交换机中的查询者根据自身的组播转发表，按照发送周期泛洪发送普遍组查询报文，并根据接收到的igmp报文，按照更新周期对组播转发表和对应端口的流表进行更新。具体的，发送普遍组查询报文模块流程如图8所示。查询者会管理一个自身的组播转发表，组播转发表存放在数据库中，表结构单元如图9所示。其中，group为组播组地址，port为true 时表示此端口有该组成员，为false则表示没有。发送普遍组查询报文模块以周期60s泛洪发送普遍组查询报文，以周期130s进行查询者组播转发表和流表的更新，每次更新后将所有的port值重置为false。如果查询者在130s内接收到了成员报告报文，则对应port值会置true，查询者每13 0s根据各组port值对组播转发表和流表进行更新，如果某组的port值皆为false，则查询者会将此group从组播转发表中删除，并删除对应的流表。
82.查询者针对成员报告报文和离组报文的处理中，需要采用不同的处理方式。具体的，如图10所示。当查询者包处理模块接收到的igmp报文为成员报告报文时，若包中的组地址未在查询者的组播转发表内，则给转发表新建组，添加对应的port并将值置为true；若组在转发表内但port不在该组内，则添加对应的port并将值置为true；若组和port皆在转发表内，则将对应的port置为true。接着给查询者添加ip地址为该组地址的数据包从查询者
其余端口发往该port的流表。当查询者处理模块接收到的 igmp报文为离组报文时，会立刻发送特定组查询报文，休眠1s后再次发送特定组查询报文，若2s内未收到成员报告报文，说明网络内已无该组的组播成员，将该组从组播转发表中删除。
83.窥探者包处理模块流程如图11所示。类似于查询者，窥探者也具有自己的组播转发表，其结构如图12所示，switch_id为承担窥探者角色的交换机id，group为组播组，reported标明此group是否回复过成员报告报文，ports为窥探者的端口集合，port：true标明此端口通往该组的组成员，反之port：false表示此端口未与该组的组成员有连接。除此之外，其还具有一个查询者端口信息表，使用和查询者相同的图9中的结构，por t为通向查询者方向的端口。窥探者会解析收到的igmp报文类型，根据不同类型分别进行查询报文处理、成员报告报文处理和离组报文处理。
84.虚拟交换机中的窥探者解析收到的igmp报文类型，根据不同类型分别进行报文处理，根据接收报文的端口学习通向查询者的端口信息，更新自身的组播转发表、对应端口的流表和查询者端口信息表。在窥探者查询报文处理中，窥探者可以通过报文进来的端口学习到通向查询者的端口信息，将此信息以图9所示结构关系存入数据库。之后进行查询报文类型判断，根据不同类型重置图12中所示表的对应reported信息，例如如果是特定组查询报文，则将特定group中的reported置为false，表示该窥探者没有收到来自该组的成员报告报文。将查询报文进行泛洪后，窥探者开启查询报文超时处理线程。在该处理线程中，根据查询报文类型的不同，传入的最长等待时间也不同，普遍组查询报文传入的最长等待时间为130s，特定组查询报文则是2s。当等待时间超过传入的最长等待时间后，若期间未接收到成员报告报文，则对应的group中的reported仍为false，窥探者将组播转发表中reported为false的group进行删除。
85.类似于查询者，窥探者针对成员报告报文和离组报文的处理中，需要采用不同的处理方式。(1)当报文为成员报告报文时，查询者和窥探者根据报文信息更新组播转发表和对应端口的流表，窥探者将报文由通往查询者的端口发出。如果报告中的组播地址未在窥探者的组播转发表中，则在组播转发表中新建，对应的reported字段设为false，对应port字段置为 false。接着根据报文进来的端口给窥探者更新流表，增加ip地址为该组地址包从窥探者其余端口发往该端口的流表和从该端口发往通往查询者的端口的流表。最后将成员报告报文从通往查询者的端口发出，并将对应的r eported字段设为true，对应port字段设为true。(2)当报文为离组报文时，窥探者将报文由通往查询者的端口发出，查询者根据报文信息更新组播转发表和对应端口的流表。针对离组报文，窥探者直接将此离组报文从通往查询者的端口发出。
86.由上述具体实施方法可以看出，本实施例提供的面向dds分布式应用的仿真方法，仅使用一台基于ubuntu 20.04镜像的vmware虚拟机，就能实现基于dds传输的分布式系统模型，且其性能良好，配置相对简单。
87.本实施例提供的dds分布式应用仿真的方法采用sdn作为基础架构搭建仿真平台,使得网络仿真拓扑可以自定义搭建，网络数据转发所需要的功能可以通过控制器灵活实现；采用docker容器作为仿真节点，使得分布式系统的业务可以根据需要灵活部署，dds中间件可以根据需求自定义选择。因此本发明的适用性更广，可以很好的解决dds在分布式系统的应用仿真验证问题。
88.实施例2：
89.在上述实施例1提供的dds分布式应用仿真的方法的基础上，本发明还提供了一种可用于实现上述方法的dds分布式应用仿真的系统。
90.如图13所示为本实施例提供的系统整体框架图，图14为本实施例提供的系统的逻辑描述图。系统架构整体分为应用层、控制层和数据层。
91.其中数据层由分布式系统业务中的众多主机节点和交换机组成，节点之间基于dds进行信息交互。数据层包括分布式系统业务中所有网元节点，节点之间基于dds进行信息交互，数据层通过北向接口与应用层进行数据交互。基于图13，数据层实现了ovs交换机与docker容器、ovs交换机以及控制器的连接。具体的，ovs通常支持tunnel port、patch port、inte rnal port、normal port等端口。如图15所示例是使用网桥连接两个doc ker容器进行通信的过程。启动容器后，通过brctl工具和ip-a查看网桥的配置情况，然后分别给容器1和容器2添加网卡并赋予ip地址，最后分别与ovs-bridge的normal port进行连接从而完成通信，normal port会将主机的物理网卡/虚拟网卡挂载在此ovs上，从这个网卡进出的数据包都会由ovs产生一个同名的端口进行处理。图15所示为两个ovs交换机基于 patch port实现通信的过程，针对每个交换机，使用ovs创建一个patch port，p1和p2分别为网桥的patch port。
92.控制层具有二层交换机转发功能和ip组播功能，用于对数据层中的网络节点进行拓扑发现，并实现地址协议解析，控制层通过南向接口与数据层中的虚拟交换机节点连接，以完成实施例1提供的dds分布式应用仿真方法。控制层由odl控制器和dds中间件(如opendds)组成，控制器用于拓扑发现和控制网络数据转发。dds中间件是基于传输层之上的中间件，负责组件之间的信息交互。控制层通过北向接口与应用层进行交互。控制层通过南向接口协议与数据层进行信息交互，主要为openflow1.3协议，odl 控制器通过此协议对虚拟交换机的数据转发进行控制。
93.在本实施例提供的系统基础上，执行实施例1提供的dds分布式应用仿真方法，即可快速有效的完成dds分布式应用系统的仿真。
94.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。