面向标准的水文监测的研究与实现

         中图分类号：TP311 文獻标识码：A 文章编号：1009-3044（2017）05-0183-04
Abstract： The hydrological monitoring system is a platform that provide all kinds of hydrological informationfor hydrological departments.Business functions are abundant，including telemetry station location，status query， real-time information and previous hydrological information query.Hydrological monitoring system need to process message sended by each remote station asynchronously， including information collection， analysis and storage，real-time information query by the page .Traditional hydrological monitoring server uses BIO way to accept the processing data.This paper uses NIO way to deal with hydrological data based on the comparison of traditional BIO and describes the design ideas and implementation of hydrological monitoring server achieved by the encapsulation and extension of the source code of Netty，which can process the request of client asynchronously.
Key words： Hydrological monitoring； NIO； Netty framework； Asynchronous
1 背景
水文监测系统主要应用与水文部门对各个地区的降水量、河道、水库（湖泊）以及地下水等的监测与统计，从而制定出相应的对策。传统的水文监测普遍采用人工监测和有线传播等方式进行，这种方式存在很严重的弊端，人工监测的成本高，信息采集的准确度不高，并且信息的实时性也不高，这样给水文部门制定相应的策略的时候造成很大的干扰。随着科学技术的不断发展，现如今的水文监测技术已经发展的比较成熟，其中主要涉及传感器技术、嵌入式技术、通信技术、存储技术、信息处理技术以及人工智能等多种高新信息技术[1]。
网络编程的基本模型是Client/Server模型，也就是两个进程之间进行相互通信，其中服务端提供位置信息（绑定的IP地址和监听端口），客户端通过连接操作向服务端监听的地址发起连接请求，通过三次握手建立连接，如果连接成功，双方就可以通过网络套接字（Socket）进行通信[2]。
2 BIO与NIO的比较
传统的网络服务器使用BIO（阻塞IO）开发，多采用一连接一线程（One thread per connection）的线程模型，即每接受一个连接请求则产生一个子线程处理该请求。如图1所示，Acceptor负责监听各个Client的连接请求，当接收到Client的连接请求之后为每个Client创建一个新的线程进行处理，处理完成之后再通过输出流返回应答消息给每个Client，之后线程销毁。
该架构最大的问题就是不具备弹性伸缩能力，当客户端数量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加，可能会发生句柄溢出、线程堆栈溢出等问题，并导致服务器最终宕机[3]。
3 Netty原理及其概述
NIO类库和API繁杂，使用麻烦工作量和难度都非常大，并且JDK NIO本身存在BUG，例如epoll bug，它会导致Selector空轮询，最终导致CPU100%[2]。目前主流的NIO框架包括Mina、Netty、Grizzly等。Mina是Apache组织的一个开源的项目，Netty从某种程度上来说是Mina的延伸和扩展，对Mina的设计上进行了一些优化。而Grizzly由sun公司开发，专门解决多客户端访问服务器时产生的各种问题。本文通过调研，决定采用Netty作为底层源码实现服务端。
Netty是一款NIO的客户端服务器框架，能够快速而简单的开发出高性能的、可维护的网络应用比如协议服务器和客户端[6]。Netty 可以通过调整参数灵活配置成Reactor 单线程、多线程和主从多线程模型，用少量的线程即可以处理上万条TCP 连接，同时Netty 中集成了主流的编解码框架和灵活的自定义编解码器实现，能轻松实现私有的协议栈[5]。

         同时Netty具有以下优点[2]： 

　　1）对原生的NIO类库进行封装，并且预置了多种编解码器，便于使用；
2）同时支持阻塞以及非阻塞的socket；
3）支持多种主流的协议，如TCP，UDP，HTTP，SMTP等；
4）可扩展性高，可以通过自定义的ChannelHandler对框架进行灵活的扩展；
5）与其他主流NIO框架相比，性能最优。
4 设计与分析
4.1 总体设计
本文是以Netty[6]为底层框架，将Netty对私有协议编解码的支持封装，提供可以解析符合水利行业标准信息报文的通用型水文监测服务端。其硬件部署图如图3所示，遥测站监测数据，通过无线通信网络发送到远端中心站进行处理。
4.2 详细设计
水文监测服务端的主要任務是处理与遥测站之间的数据交互，这里主要指的是各类水文信息报文。水文信息报文帧结构如表1所示，采用中华人民共和国水利部规定的水文监测数据通信规约[7] ，报文正文主要由两类报文构成，一是遥测站主动发送给服务端的报文，包括链路维持报，测试报，均匀时段水文信息报，遥测站定时报，遥测站小时报等；二是中心站查询信息报文，包括中心站查询遥测站实时数据，中心站查询遥测站时段数据，中心站查询遥测站指定要素实时数据，中心站修改遥测站基本配置数据，中心站查询遥测站状态和报警信息等。
4.2.1 TCP粘包/拆包
服务端从网络中接收到的是一系列二进制的数据，这些数据在未处理之前，用户是无法识别的，因此，对这些数据的解析就显得尤为重要。
数据传输的过程中，TCP底层并不了解上层的业务，在包划分时，只会根据自身缓冲区进行，因此，不能保证接收到的消息为整包消息。现假设客户端向服务端发送两个数据包B1，B2，则服务端在接收客户端数据时可能存在以下几种情况[2]：
1）服务端分两次收到了两个完整的独立的数据包；
2）服务端一次收到了两个粘在一起的包，即TCP粘包；
3）服务端分两次收到两个数据包，第一次的包是完整的B1和部分B2，第二次的包是余下的B2；
4）服务端分两次收到两个数据包，第一次是部分B1，第二次是余下的B1和完整的B2；
5）当数据包比较大而缓冲区比较小的时候，服务端分多次才能将B1，B2接收完全。 (责任编辑：论文发表网)转贴于八度论文发表网: http://www.8dulw.com(论文网__代写代发论文_论文发表_毕业论文_免费论文范文网_论文格式_广东论文网_广州论文网)