目录
背景
主线
协议
1、各方关系
2、协议简介
背景
最近在做905协议,本想着靠着度娘扒拉下代码参考一下,发现资源非常有限,于是就只有自己动手实现了一番,也踩了几个坑。
本着开源共享的精神,分享下我实现的过程,也做一个分享记录。这就是我写 JT905 的初衷。
主线
一、协议的简单讲解(本篇);
二、整体设计与协议实现;
三、netty简单讲解与接收端实现;
四、保存端实现;
协议
版本:JT/T 905.4-2014
1、各方关系
在建设实现 905 协议服务之前,需要明确各个系统间的关系,除非是终端承建平台,业务平台都是属于上级平台,只接收 905 协议的数据,所以建设的都是上级平台(接收端);而只有少数的项目,例如大数据中心等才有可能会作为下级平台推送数据。各方关系如下图:
2、协议简介
-
下级平台登录上级平台
-
心跳(链路保活)
-
数据交互
-
连读断开
心跳需要注意时间规定:
4.3.1.2 链路保持流程 链路保持流程应遵循以下规定:
a) 下级平台登录成功后,在与上级平台之间如果有应用业务数据包往来的情况下,不需要发送链路保持数据包;否则,下级平台应每隔 1min 发送一个链路保持请求数据包到上级平台以保持链路连接;
b) 在没有应用数据包往来的情况下,上级平台连续 3min 未收到下级平台发送的链路保持请求数据包,则认为与下级平台的连接中断,将主动断开数据传输链路;
c) 在没有应用数据包往来的情况下,下级平台连续 3min 未收到上级平台发送的链路保持应答数据包,则认为与上级平台的连接中断,将主动断开数据传输从链路。
即空闲时每分钟下级平台需要发一次心跳包,而上级平台需要回复心跳包;超时时间为3分钟。心跳包有规定,不需要携带数据体,但是依然由头标志、消息头、CRC校验码、尾标志,详见协议规定。
(本图请结合协议规定的结构观看会更容易理解)
消息头和消息体中的数据,只需要按照协议的规定进行解析即可,因为协议中规定了顺序和每个数据长度,复杂度不高。
需要注意的点是:消息头中的 msg_id
是消息类型,但代表的是一级类型,其值的规定在 5.1 章节中;而在 4.5.3 章节中的动态数据业务类中又规定了 子业务类型
,这个子业务类型是消息体的 DATA_TYPE
,其值的规定在 5.2 章节中,需要注意不要搞混了。
需要吐槽的是:4.5.3.1 章节规定的实时车辆定位消息体报文中,DATA_TYPE 在最前面,是很利于数据解析的,但是在 4.5.3.3 章节规定的车辆定位信息自动补报消息体报文中,DATA_TYPE 既然被规定在了第3位,导致需要特殊处理,放在第1位难道不好么?
定义:CRC即循环冗余校验码(Cyclic Redundancy Check):是数据通信领域中最常用的一种查错校验码,其特征是信息字段和校验字段的长度可以任意选定。
我本来想深入学习一下,但是通过度娘找到的资料有限,没有真正弄明白,在这里就不过多的讲解。并且通过度娘找到的 CRC 计算实现代码有坑,不准确。无奈找到在线计算器,扒拉里面的逻辑写出了 CRC 校验码。
比较有用的博客(是C语言的实现):C语言版CRC-16系列校验算法_我伴你度过明天的博客-CSDN博客_crc16校验
在线计算器:CRC(循环冗余校验)在线计算_ip33.com
由于头标志和尾标志已经固定规定为:0x5b 和 0x5d ,在 4.4.4 章节中就规定了字符转义
4.4.4 标示位
头标识为字符 0x5b。
尾标识为字符 0x5d。
若校验码、消息头以及消息体中出现头尾标识字符,则要进行转义处理,转义规则如下:
a) 若数据内容中有出现字符 0x5b 的,需替换为字符 0x5a 紧跟字符 0x01;
b) 若数据内容中有出现字符 0x5a 的,需替换为字符 0x5a 紧跟字符 0x02;
c) 若数据内容中有出现字符 0x5d 的,需替换为字符 0x5e 紧跟字符 0x01;
d) 若数据内容中有出现字符 0x5e 的,需替换为字符 0x5e 紧跟字符 0x02。
所以实现的时候一定要注意转义。
并且从这个规定中可以看出协议中没有说明的点:数据在传输前,需要转换为16进制字符串的 byte 数组再传递,并且协议中规定的每个字段占用的 byte 数,也是指的16进制的数据,而不是原数据。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)