基于socket报文的数据解析

基于socket报文的数据解析

摘要：目前国内外大多数实时监测系统都采用socket方式来进行网络通信。结合高速铁路道岔监测系统中的实时数据解析实例，在明确了解各种环境监测项的基础之上，制定socket报文协议，在qt（q toolkit）开发环境下，利用工厂模式来实现socket 报文的解析。结论：此模式适合于高速铁路岔道系统中监测项已经明确的解析环境。

关键词：工厂模式；socket报文；qt解析

中国分类号：tp39 文献标识码：a

文章编号10053824（2013）01006803

0 引言

采用计算机网络进行远程数据通讯，具有通讯可靠和速度快的优点。tcp/ip网络协议是目前广泛采用的一组完整的网络协议。socket提供基于tcp/ip网络的应用编程接口，采用客户机和服务器通信机制，通过socket可以实现网络之间的连接与数据解析和交换。

高速铁路对实时安全性要求比较严格，所以在设计高速铁路道岔监测系统时，数据能否实时传输与正确解析就显得极其重要。针对这种情况，提出利用socket报文来实现数据传输与正确解析。同时，根据高速铁路道岔系统中监测项较多，且监测种类已经明确的情况，提出利用工厂模式来实现数据解析。即：在工厂模式下，建立工厂类。其优点是明确了各自的职责和权利，有利于整个软件

体系结构的优化[13]。

本文提出利用工厂模式来实现基于socket报文的数据解析与处理，从而更好地满足高速铁路道岔监测系统对于数据实时正确解析的要求。

1 socket报文

1.1 socket报文的数据格式

根据实际情况定义socket报文的数据格式如表1所示。

1.2 socket报文不同字段含义简介

1）长度l。长度l为用户数据长度，由2字节组成，是控制域、地址域、应用功能码、业务数据的字节总数，为short int类型。

表1 socket报文的定义

长度（字节） socket数据定义

1 起始字符（68h）

2 长度l

1 起始字符（68h）

2 控制域c

8 地址域a

2 应用功能码afn

由业务类型确定业务数据

暂定为0 消息认证码pw

1 结束字符（16h）

2）控制域c。控制域c表示报文传输方向和所提供的传输服务

类型的信息，由2个字节组成。

3）地址域。地址域由8个字节组成，是设备的唯一标示。

4）应用功能码。应用功能码afn由2个字节组成，为short int 类型。

5）业务数据。业务数据是由数据单元构成的集合，业务数据可能包含n组数据单元。数据单元由数据单元标识和数据体构成。

6）消息认证码。消息认证码字段pw用于重要下行报文中，长度由认证算法决定，暂时为空。pw是由主站按系统约定的认证算法产生，并在主站发送的报文中下发给终端，由终端进行校验认证，通过则响应主站命令，反之则否认，并且终端在收到带有pw的报文，必须在认证通过后，才能响应命令[4]。2 基于socket报文格式的数据解析

2.1 工厂设计模式

工厂设计模式的思想是把创建对象的责任和使用对象的责任分开，工厂负责统一创建具体产品，然后再把这些产品转化为他们的抽象产品，返回给外部使用者，作为使用者关心的仅仅是抽象产品预留的接口，而不关心他们是怎么创建的。这样核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节[56]。

2.2 利用qt实现数据解析

2.2.1 根据afn功能码创建多态类

高速铁路道岔实时环境监测系统主要接收并展示传感器传输的4个监测内容数据：设备维护状态数据、心跳信号数据、温湿度数据以及温湿度处理状态数据。为了区分这4种数据，我们引入afn 功能码概念，利用afn功能码来区分是维护标示数据，还是心跳信号数据，还是温湿度数据，还是温湿度采集器状态数据，从而建立了一个抽象类（data process），以及4个子类心跳信号处理类（heart beat process）、维护状态处理类（manage status process）、温湿度数据处理类（weather data process）和温湿度状态处理类（weather status process）。整体类图如1所示。

3）socket报文解析截图分析。

解析结果如图3所示：道岔平台id为101；车站id为10001；道岔编号为10001；监测项目id为5，代表温湿度数据监测；道岔周边温度为31.9 ℃，温度告警显示正常；湿度为49%rh，湿度告警显示正常。该数据监测时间为20120707t16：56：12。

4 结语

本文结合高速铁路道岔监测系统中的实时数据解析实例，在明确了各种环境监测项的基础之上，制定socket报文协议，利用工厂模式来实现解析。

此种模式适合于高速铁路道岔系统中监测项等已经明确的实时解析环境中，但此种模式也存在一定的缺点：由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如

果需要添加新的类，则就需要改变工厂类了。当系统中的具体产品类不断增多时，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统维护和扩展非常不利。

根据工厂模式的缺点，下一步将会研究利用工厂方法模式来对此种模式的缺点来进行改进，以提高该解析方法效率。参考文献：

[1] 谢希仁.计算机网络[m].北京：电子工业出版社，2008.

[2] xteam（中国）软件技术有限公司.qt程序设计[m].北京：清华大学出版社，2002.

[3] shalloway a， trott j r.设计模式精解[m].北京：清华大学出版社，2004.

[4] 多纳霍，卡尔福特. tcp/ip sockets编程[m].陈宗斌，译.北京：清华大学出版社，2009.

[5] 傅瑜光，陈刚.基于socket的报文通讯异步转换期的设计与实现[d].北京：清华大学软件学院，2004.

[6] 周坤，傅德胜.基于windows socket的网络数据传输与安全[d].南京：南京信息工程大学计算机与软件学院，2007.