专利名称：一种分组交换网络高效实时数据交互协议及通信方法
技术领域：
本发明涉及分组交换网络协议，具体说是一种分组交换网络高效实时数据交互协议及通信方法。
背景技术：
矿井事故的发生随着煤矿开采力度的加大，日益增多。煤矿开采、掘进、运输等整个生产过程都受瓦斯、一氧化碳、煤尘等因素的严重威胁。所以，在工程进行之前，对矿井安全因素的分析，显得尤为必要。由于煤矿井下的特殊性，制约了井下无线通信系统的发展。我国井下无线通信系统一直主要靠引进吸收国外的相关技术，但随着近年来地面无线技术的快速发展以及我国科技研发的不断投入，新型的无线技术越来越多的服务于煤矿井下。我国煤矿的大部分矿井没有装备无线通信系统，已经装备无线通信系统的矿井中，也很难真正发挥效能为煤矿生产和安全服务，系统使用效果不理想。目前，矿井中所使用的无线通信技术主要有感应通信和漏泄通信。但是感应通信由于体积限制，输出功率较小，不宜用于环境噪声大的场所，而漏泄通信要求必须有专用的信道，使得系统的造价较闻。为解决感应通信、漏泄通信存在的缺点，国外开发了煤矿井下超低频透地通信系统，它是以大地为传播媒介，令无线电波直接透过大地来实现地面与井下通信的一种方式。瓦斯实时监测技术和煤层瓦斯含量快速测定技术以及网络化技术是改善、提高煤矿安全生产的几个主要手段。通过瓦斯实时监测技术，煤矿管理和技术人员能够随时从生产控制室里了解到工作面瓦斯浓度的变化。根据这些变化，他们采取不同的瓦斯控制技术措施，或继续生产，或加强通风，或抽放瓦斯，甚至停止生产等。实时瓦斯监测技术系统能够监测工作面瓦斯浓度，捕捉井下局部瓦斯浓度变化，并根据瓦斯浓度采取断电等措施，防止事故的发生。在网络化技术的推进中，煤矿安全数据传输的可靠性、安全性和实时性成为煤矿安全实时监测系统中重要的一环，是一个非常重要的研究课题。随着矿井开采深度增加，系统的扩展，现行网络难以确保重要的安全数据、控制数据和井下仪表的检测数据不受延迟或丢失。而且井下环境恶劣，电磁干扰强，粉尘大，湿度高，使得网络的数据可靠性和实时性得不到保证。
发明内容
为解决上述问题，本发明目的在于提供一种分组交换网络高效实时数据交互协议及通信方法，通过定义数据包报文，制定客户端服务器通信方法，进而构成分组交换网络高效实时数据交互协议。为实现上述目的，本发明采用的技术方案是:一种分组交换网络高效实时数据交互协议及通信方法，其特征在于:请求数据交互包括以下步骤:
步骤I)客户端向服务器发送Request报文；若未收到服务器返回的Reqresponse报文，则重新发送Request报文，尝试失败后认为服务器不可连接，不再重传，返回起始状态；步骤2)服务器接收到客户端的Request报文后，向客户端发送一个带有对应响应码Reqresponse报文；若未收到客户端返回的ReqACK报文,则重新发送Reqresponse报文，尝试失败后认为客户端不可连接，不再重传，返回起始状态；步骤3)客户端接收到服务器的ReqACK报文后，向服务器发送一个带有确认码的ReqACK 报文；步骤4)服务器接收到客户端的ReqACK报文后，向客户端发送Notify报文；在Request报文指定的有效时间内，向客户端以Request报文指定的数据间隔为周期发送Notify报文,传送实时数据；步骤5)有效时间到期时，服务器发送一个终止Notify报文。所述Request报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。所述Reqresponse报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。所述ReqACK报文数据请求确认报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。所述Notify报文包括4位版本号；4位包类型；1位终止位；7位参数个数；16位请求序号；32位通知序列号；16传感器编号；16位参数类型；32位参数值；32位校验和。所述起始状态为空闲状态。所述有效时间为该数据请求报文的有效时间，响应该报文的服务器在有效时间内不断向客户端发送数据响应报文。 所述数据间隔为在有效时间内服务器向客户端发送数据响应报文的时间间隔。所述实时数据为在服务器端的传感器所采集的数据。还包括控制命令交互，具体为以下步骤:步骤I)客户端向服务器发送Command报文；若未收到服务器返回的CmdResponse报文，则周期性发送Command报文，尝试失败后不再重传，返回起始状态；步骤2)服务器接收到客户端的Co_and报文后，向客户端发送一个带有对应响应码的CmdResponse报文；若未收到客户端返回的CmdACK报文,周期性发送CmdResponse报文，尝试失败后不再重传；返回起始状态；步骤3)客户端接收到服务器的Cmdresponse报文后，发送一个带有对应确认码的CmdACK 报文。所述Co_and报文包括4位版本号；4位包类型；8位保留位；16位命令包序号；16位传感器编号，16位控制命令；32位命令选项；32位校验和；所述CmdResponse报文包括4位版本号；4位包类型；8位保留位；16位响应序号；32位响应码；32位校验和；所述CmdACK报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。
本发明具有以下有益效果及优点:1.本发明设计了一种分组交换网络高效实时数据交互协议，使本协议具有较高的网络吞吐率。2.本发明设计了一种分组交换网络高效实时数据交互通信方法，使本协议具有较好的传输实时性。
图1是本发明的请求数据交互过程示意图；图2是本发明的控制命令交互过程示意图；图3是本发明的数据请求报文的数据包格式示意图；图4是本发明的数据请求响应报文的数据包格式示意图；图5是本发明的数据请求确认报文的数据包格式示意图；图6是本发明的数据通知报文的数据包格式示意图；图7是本发明的控制命令报文的数据包格式示意图；图8是本发明的控制命令响应报文的数据包格式示意图；图9是本发明的控制命令确认报文的数据包格式示意图；图10是本发明的客户端状态转移图；图11是本发明的服务器状态转移图。
具体实施例方式下面结合附图及实施例对本发明做进一步的详细说明。本发明是一种分组交换网络高效实时数据交互协议及通信方法，本实施例用于服务器与客户端之间进行分组交换。本协议包括分组交换网络高效实时数据交互协议的协议数据包报文和协议通信控制。协议数据包报文包括数据请求报文、数据请求响应报文、数据请求确认报文、数据通知报文、控制命令报文、控制命令响应报文和控制命令确认报文。如图3所示，数据请求报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。版本号指协议的版本号，本协议版本号从O开始。数据包类型包括数据请求(Request)、数据请求响应(ReqResponse)、数据请求确认(ReqACK)和数据通知(Notify)及控制命令(Command)、控制命令响应(CmdRequest)和确认(CmdACK)五种。保留位，保留为将来版本使用，置O。请求序号可用于接收方发现丢失包以及恢复包序列，序号初始值为1，每传输一个非终止数据请求报文该序号递增I。有效时间为该数据请求报文的有效时间，响应该报文的服务器应在有效时间内不断向客户端发送数据响应报文，该整型数字值，单位为秒。数据间隔为在有效时间内，服务器向客户端发送数据响应报文的时间间隔，整型数字值，单位为毫秒。有效时间和数据间隔均置为O时，表示此报文为终止数据请求报文，该报文的请示序号应与前一个发送并得到确认的数据请求报文相同。校验和为协议数据包首部CRC校验和。如图4所示，数据请求响应报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。响应码为服务器对收到的数据请求报文做出的响应内容。如图5所示，数据请求确认报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。确认码为客户端对收到的数据请求响应报文做出的确认内各。如图6所示，数据通知报文包括4位版本号；4位包类型；1位终止位；7位参数个数；16位请求序号；32位通知序列号；16传感器编号；16位参数类型；32位参数值；32位校验和。终止位表示数据包是否为最后一个数据通知报文。该位为I时为终止报文，为O时为非终止报文。参数个数为数据通知报文携带的参数个数，即不同环境数据的个数。所述通知序号用于接收方发现丢失包以及恢复包序列，初始值为I，每传输一个数据通知报文该序号递增I。所述传感器编号为要提供参数的传感器的编号，下同。参数类型个数由参数个数指定，每个头域与紧随其后的参数值对应。所述参数值用来指定一个参数的值，值的类型、含义及范围由其前面的参数类型确定，一对参数类型和参数值表示一个参数。如图7所示，控制命令报文包括4位版本号；4位包类型；8位保留位；16位命令包序号；16位传感器编号，16位控制命令；32位命令选项；32位校验和。命令包序号用于接收方发现丢失包以及恢复包序列，初始值为I，每传输一个控制命令报文该序号递增I。控制命令表示传输的控制命令。命令选项表示控制命令的具体选项，选项的类型及含义与对应的控制命令有关。如图8所示，控制命令响应报文包括4位版本号；4位包类型；8位保留位；16位响应序号；32位响应码；32位校验和。如图9所示，控制命令确认报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。确认序号表控制命令确认报文对应的控制命令响应报文，确认序号与控制命令响应报文的响应序号及控制命令报文的命令包序号相同。确认码表示客户端对收到的控制命令响应报文做出的确认内容。分组交换网络高效实时数据交互协议的通信方法包括请求数据交互和控制命令交互。请求数据以客户端/服务器(Client/Server)方式工作，客户端与服务器的交互过程分为请求(Request)、响应(Reqresponse)、确认(ReqACK)、通知(Notify)四个主要阶段。如图1所示，请求数据交互过程如下:Al.客户端向服务器发送Request报文。若未收到服务器返回的Reqresponse报文，则每隔2秒重新发送Request报文，尝试5次失败后认为服务器不可连接，不再重传；A2.服务器接收到客户端的Request报文后，应在检查Request报文的有效性后，向客户端发送一个带有对应响应码Reqresponse报文。若未收到客户端返回的ReqACK报文，则每隔2秒重新发送Reqresponse报文，尝试5次失败后认为客户端不可连接，不再重传；A3.客户端接收到服务器的ReqACK报文后，应根据响应码内容向服务器发送一个带有对应确认码的ReqACK报文。并准备开始做下一步行为；
Α4.服务器接收到客户端的ReqACK报文后，开始向客户端发送Notify报文。在Request报文指定的有效时间内，向客户端以Request报文指定的数据间隔为周期发送Notify报文,传送实时数据；A5.有效时间到期时，服务器发送一个终止Notify报文。请求数据交互还包括请求数据机制，周期刷新机制和请求数据终止传输机制。请求数据机制为:当客户端发送请求后，服务器在与其三次握手确认后，在指定的有效时间之内，按照指定的频率向控制台发送数据。周期刷新机制为:客户端在有效时间后需要继续请求数据或要求重新指定有效时间和数据间隔，可发送Request报文刷新有效时间和数据间隔，请求服务器按照新的方式发送数据。请求数据终止传输机制包括正常终止和主动终止。正常终止为:有效时间到期时，客户端未发送刷新Request报文，服务器向客户端发送一个终止Notify报文后，停止发送Notify报文，客户端此时应停止接受Notify报文。所述主动终止为:在有效时间内，客户端要求停止Notify的传输，向服务器发送一个将终止Notify报文,并停止接收Notify,客户端收到终止Notify报文后，应停止接收Notify报文。控制命令分为命令(Command)、响应(CmdResponse)、确认(CmdACK)三个阶段。控制命令处理流程如下:B1.客户端向I服务器发送Command报文。若未收到服务器返回的CmdResponse报文，则每隔2秒重新发送Command报文，尝试5次失败后认为服务器不可连接，不再重传。B2.服务器接收到客户端的Co_and报文后,应在检查Co_and报文的有效性后，向客户端发送一个带有对应响应码的CmdResponse报文。若未收到客户端返回的CmdACK报文，则每隔2秒重新发送CmdResponse报文，尝试5次失败后认为客户端不可连接，不再重传。B3.客户端接收到服务器的Cmdresponse报文后,应根据响应码内容向服务器发送一个带有对应确认码的CmdACK报文。如图10所示，客户端状态转移图包括空闲状态(IDLE)、请求发送(REQ_SENT)、请求响应接收(REQRESP_REVD)和通知接收(N0TIFY_REVING)以及命令发出(CMD_SENT)和命令响应接收(CMDRESP_REVD)六个状态。左半部分为数据请求的状态，右半部分为控制命令的状态。起始状态和唯一的接受状态均为IDLE状态。如图11所示，服务器状态转移图也包括监听(LISTEN)、请求接收(REQ_REVD)、请求响应发送(REQRESP_SENT)以及通知发送(N0TIFY_SENDING)以及命令接收(CMD_REVD)和命令发出(CMDRESP_SENT)六个状态。左半部分为数据请求的状态，右半部分为控制命令的状态。起始状态和唯一的接受状态均为LISTEN状态。
权利要求
1.一种分组交换网络高效实时数据交互协议及通信方法，其特征在于:请求数据交互包括以下步骤: 步骤I)客户端向服务器发送Request报文；若未收到服务器返回的Reqresponse报文，则重新发送Request报文，尝试失败后认为服务器不可连接，不再重传，返回起始状态； 步骤2)服务器接收到客户端的Request报文后，向客户端发送一个带有对应响应码Reqresponse报文；若未收到客户端返回的ReqACK报文,则重新发送Reqresponse报文，尝试失败后认为客户端不可连接，不再重传，返回起始状态； 步骤3)客户端接收到服务器的ReqACK报文后，向服务器发送一个带有确认码的ReqACK 报文； 步骤4)服务器接收到客户端的ReqACK报文后，向客户端发送Notify报文报文指定的有效时间内，向客户端以Request报文指定的数据间隔为周期发送Notify报文，传送实时数据； 步骤5)有效时间到期时，服务器发送一个终止Notify报文。
2.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述Request报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。
3.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述Reqresponse报文包括4位版本号；4位包类型；8位保留位；16位请求序列；16位有效时间；16位数据间隔；32位校验和。
4.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述ReqACK报文数据请求确认报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。
5.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述Notify报文包括4位版本号；4位包类型；1位终止位；7位参数个数；16位请求序号；32位通知序列号；16传感器编号；16位参数类型；32位参数值；32位校验和。
6.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述起始状态为空闲状态。
7.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述有效时间为该数据请求报文的有效时间，响应该报文的服务器在有效时间内不断向客户端发送数据响应报文。
所述数据间隔为 在有效时间内服务器向客户端发送数据响应报文的时间间隔。
8.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于:所述实时数据为在服务器端的传感器所采集的数据。
9.根据权利要求1所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 还包括控制命令交互，具体为以下步骤: 步骤I)客户端向服务器发送Command报文；若未收到服务器返回的CmdResponse报文，则周期性发送Co_and报文，尝试失败后不再重传，返回起始状态； 步骤2)服务器接收到客户端的Command报文后，向客户端发送一个带有对应响应码的CmdResponse报文；若未收到客户端返回的CmdACK报文,周期性发送CmdResponse报文,尝试失败后不再重传；返回起始状态； 步骤3)客户端接收到服务器的Cmdresponse报文后，发送一个带有对应确认码的CmdACK 报文。
10.根据权利要求9所述的一种分组交换网络高效实时数据交互协议及通信方法，其特征在于: 所述Command报文包括4位版本号；4位包类型；8位保留位；16位命令包序号；16位传感器编号，16位控制命令；32位命令选项；32位校验和； 所述CmdResponse报文包括4位版本号；4位包类型；8位保留位；16位响应序号；32位响应码；32位校验和； 所述CmdACK报文包括4位版本号；4位包类型；8位保留位；16位确认序号；32位确认码；32位校验和。
全文摘要
一种分组交换网络高效实时数据交互协议及通信方法，包括分组交换网络高效实时数据交互协议的协议数据包报文和协议通信控制。协议通信控制包括数据请求交互和控制命令交互，数据请求交互过程包括请求(Request)、响应(Reqresponse)、确认(ReqACK)、通知(Notify)四个主要阶段；控制命令交互过程包括命令(Command)、响应(CmdResponse)、确认(CmdACK)三个阶段。本发明设计的分组交换网络高效实时数据交互协议具有较高的网络吞吐率并具有较好的传输实时性。
文档编号H04L12/70GK103166843SQ20111041923
公开日2013年6月19日 申请日期2011年12月14日 优先权日2011年12月14日
发明者王剑, 吕莎莎, 马跃, 于波, 孙建伟, 贾军营, 吕昕, 王卫, 李明华 申请人:中国科学院沈阳计算技术研究所有限公司