基于NIO网络模型远程实验系统设计

卢国宝,陈锡爱,胡 群,潘 和

(1.中国计量大学 机电工程学院,浙江 杭州 310018;2.亚龙智能装备集团股份有限公司,浙江 温州 325105)

基于计算机网络技术的发展,远程教育得到了快速发展,其中,远程实验是远程教育中重要的研究课题之一[1],在楼宇实训室领域,Niagara软件基于可视化逻辑编程开发,使用难度低,并且可以连接任何设备厂家的设备和不同的通讯协议,有着广泛的应用,是各职业技术学院实验室的首要选择。当前,国内外学者针对不同的领域提出了不同的远程实验方案。杭州电子科技大学基于云服务器实现了用户和FPGA的双向远程通信[2],美国Univeristy of Tennessee at Chattanooga通过Web服务器实现了压力控制实验。美国德科萨斯州实验室通过MSN-NetMeeting技术实现了倒立摆的远程控制实验[3]。

尽管取得了以上进展,但上述方法大都从单一领域出发,扩展性低,考虑到远程实验室场景多样性,可以设计一套统一的接入方案,来实现多场景接入。因此,本文提出了一种新软件架构。新的软件架构提供了标准接口协议,针对实现了相应协议的软件平台即可实现远程实验功能的接入;基于新的配对算法实现了学生和设备点对点配对;选取NIO网络模型降低了云服务器系统资源的开销,提高了系统的并发度。实验结果表明,本文实现的远程实验系统设计可以真实的远程操控CVT-IOT开发板,实现双方数据的交互,满足远程实验需求。

1 实验设备介绍

本文以YL-730A型设备上CVT-IOT开发板作为主要实验对象,其包含8路DI、8路DO、8路AI、8路AO,可模拟相应的输入输出情况。在软件部分,选取Tridium公司开发的软件Niagara。它集成了不同的控制系统、物理设备和通信协议。它支持的通信协议包括ModbusTCP、LonWorks、MQTT等,根据不同的协议提供相应的图形化界面,便于图形化开发[4]。系统软件开发图如图1。

图1 系统软件开发图Figure 1 System software development diagram

2 实验整体设计方案

系统的整体主要包括,实验室设备端、实验室客户端、云服务器、学生端客户端、Niagara软件;系统架构图如图2。

图2 系统整体架构图Figure 2 Overall system architecture diagram

各部分功能如下:

1) 实验室设备端:采用CVT-IOT实现服务器功能,提供相应接口供客户端进行数据查询和设置;

2) 实验室客户端:作为实验室设备端的客户端,实现向实验室设备端通信。作为云服务器的客户端,实现向云服务器端通信。同时,在两个客户端之间进行数据交换;

3) 云服务器:实现基于NIO网络模型的服务器开发,实现双方配对算法并基于配对算法进行数据转发;

4) 学生端客户端:作为云服务器的客户端,实现向云服务器端通信。作为Niagara的服务端,实现向Niagara进行通信,同时,在客户端和服务器之间进行数据交换。

2.1 实验室客户端设计

实验室客户端主要解决网络模型选型与搭建,解决客户端之间信息交互等相关问题。

2.1.1 实验室客户端网络模型选型

当前网络模型主要分为BIO、NIO和AIO三种类型。

BIO模型:全称Blocking IO,同步阻塞IO模型。客户端发起IO请求后,服务端将创建一个线程来实现网络数据传输。

NIO模型:全称Non-Blocking IO,同步非阻塞IO模型。采用IO多路复用技术,通过多路复用选择器查看IO数据是否就绪,当缓存区数据准备完毕后,再进行处理。NIO网络模型适用于服务器连接数量多,传输数据量少的场景。

AIO模型:全称Asynchronous IO,异步非阻塞IO模型。当缓冲区就绪后,异步通知线程的回调函数。但当前主流操作系统没有相应的内核函数支持。

由于实验室客户端同实验室设备进行通信,同时,又作为云服务器的客户端和云服务器通信。所以,在网络选型时,需根据通信对象的不同,选取合适的网络模型。由于实验室设备采用BIO网络模型,所以,实验室设备端的客户端选取BIO网络模型通讯方式。作为云服务器的客户端,由于云服务器连接数较多,采用NIO网络模型[5]。

2.1.2 客户端之间通讯方式

实验室设备的客户端需要同云服务器的客户端进行通信。如果,两个客户端进行独立启动会涉及进程通信而提高系统复杂性。为了避免进程间通信,将两个客户端在一个进程中进行启动,同时为了解决双客户端通信问题,引入了生产者和消费者模式,实现双方解耦。其示意图如图3。

图3 双客户端通讯示意图Figure 3 Double client communication diagram

通过生产者和消费者模式来解决双客户端通信问题,提高了系统的扩展性。

2.2 云服务器服务端的设计

云服务器的服务端主要解决网络模型选型与搭建,以及配对算法实现等相关问题。

2.2.1 网络模型的选型

本文基于Java语言实现了服务器端网络模型。针对BIO模型,它的优点是实现简单、在大数据量传输和并发量少场景下传输性能优秀[6]。在远程实验场景下,传输实验数据量有限,有一定的连接数和并发量。所以,不适合当前使用场景。针对AIO网络模型,在理论上,少了监听器会提高系统的效率,当部署在Linux时,缺乏内核函数的支持。底层原理同NIO网络模型一致,是一种伪异步方案[7]。所以,我们选取NIO网络模型来实现远程实验系统设计。

2.2.2 NIO网络模型实现

NIO网络模型的实现,需要Selector选择器的帮助,根据轮询接听实现一个线程对多个客户端的数据进行处理转发[8]。云服务端系统设计流程图如图4。

图4 Server流程图Figure 4 Flow chart of the Server

2.2.3 配对算法的实现

当服务器收到客户端数据时,需要将数据进行转发到相应的客户端。因而需要设计一种配对算法来实现数据的精准配对。

配对算法需要解决以下两个问题。

实现设备端和学生端匹配功能、根据每节课时长加入自动过期策略,实现设备提前下线功能。基于以上功能,设计如下:

当服务器收到Readable事件时,判断是否是配对数据,以id=开头时,则为配对数据,启动配对算法。若不是的话,就进入到转发流程,将数据转发到对应的客户端中。在配对算法中,初始化两个idMap、matchMap来存储相关信息,idMap作为第一个配对客户端,matchMap作为第二个配对客户端。先获取配对客户端的ip和端口号信息。查看idMap是否有相应的数据。如果,idMap不存在客户端的ip和端口号,则将key=id、value=ip+port添加到idMap中。如果,idMap中存在,matchMap中不存在,则添加到matchMap。如果,两个Map都存在的话,这证明设备被已经连接,获取失败。由于,每节课具有固定时长,在加入Map时,提交延时任务到线程池中,实现自动过期策略[9,10]。同时,当某一方发送quit命令时,也会提前触发下线操作。其算法流程图如图5。

图5 配对算法流程图Figure 5 Flow chart of pairing algorithm

2.3 学生端客户端的设计

学生端客户端主要功能是作为云服务器的客户端与云服务器进行通讯,同时作为Niagara的服务器端和Niagara进行通讯,并将它们的通讯内容进行转发。其网络模型选型与实现,服务器与客户端双方通讯与同上文相似,针对Niagara本身是一个客户端[11],其本身可以同云服务器进行通讯,而选择加入学生端客户端设计的问题,主要有如下考虑:

1) Niagara是一个集成框架,基于Niagara平台进行开发会增加成本;

2) 实现各部分解耦,实现软件分层,将增添功能在学生端客户端进行实现。当需要适配其他软件系统时,直接接入,无需更改配套程序。

3 系统测试

系统测试的主要工作是测试整体系统稳定性和网络传输的延时情况。在系统测试之前,我们首先需要对Java虚拟机来进行参数调优。由于采用了Java编程,Java程序是运行在虚拟机上的,我们需要先对虚拟机内存大小进行合适的设置[12]。如果设置得太小,则容易导致STW时间过长,影响用户体验,并且Niagara带有轮询机制,超时时间过久的话,会导致远程实验失败。如果内存设置得太大,则需要提升云服务器的配置,增加用户成本。

3.1 虚拟机内存设计与调优

内存分为堆内存、栈内存、本地方法栈和方法区内存。在调优的过程中,主要是针对堆内存和栈内存来展开。当启动项目时,根据本机的配置,系统会自动给虚拟机动态分配堆内存、栈内存和方法区内存等。为了验证系统的性能,针对一个班级40个同学同时实验的情况,设计了80个客户端,以每秒发送一条ModbusTCP协议指令[13,14],每条指令包含12个byte。通过JVM指令集对内存监控可得,在当前使用场景下,Survivor区和Old区使用率为0。Eden区使用比例也不是很高。而且,随着使用时间的变长,并没有新对象的产生,内存使用量也没有增加。所以,可以减少系统内存的使用量。设置JVM堆内存30 MB、新生代内存为20 MB、Survivor区为2 MB、栈内存为1 MB、元空间1 MB[15],由于垃圾收集情况出现较少,产生活跃对象较少,选取默认垃圾收集器即可。

3.2 远程实验室功能实现

在学生端,学生需要启动Java客户端,而后输入教师分配的id=xxx配对密码进行配对。所设计的Java客户端如图6。

图6 Java客户端示意图Figure 6 Java client diagram

当配对成功后,启动Niagara客户端,进行图像化编程,实现实验相关逻辑。在Niagara中,对远程的4路AI、4路DI、8路DO、4路AO进行采集和控制。实验采集和控制界面如图7。

图7 Nigara实验图Figure 7 Nigara experimental diagram

3.3 远程实验室延时性测试

为了减少云服务器线程资源的消耗,采用了NIO网络模型。此时,一个线程就可以实现数据的转发。但是,当用户数据发送量较大时,可能会导致网络传输速率的下降。为此,在40个学生做实验的基础上,通过模拟发送频率,来测试系统转发速率。测试结果如表1。

表1 实验模拟测试速率情况图Table 1 Experimental simulation test rate diagram

通过测试,基本验证了NIO网络模型的特点,根据学生实验场景,数据发送量可以支撑40个同学远程实验的需求。

4 结 语

本文设计了一套基于NIO网络模型的远程实验系统。通过对实验场景分析,采用了NIO的网络结构模型,使用生产者和消费者模式,实现了实验室客户端和学生端客户端内部解耦。基于云服务器客户端配对需求,提出了一种配对算法。针对40个同学同时实验场景,对JVM虚拟机进行监控与调优和远程实验延时性测试。该远程实验系统能够帮助学生在Niagara软件编程的基础上,通过NIO网络架构,远程操控YL-730A设备上的相关实验,并返回真实实验数据。同时,该远程实验系统可接入性强,不依赖于指定的软件平台和实验平台;只需满足标准的ModbusTCP协议,即可实现扩展接入。