业务场景
- 我们公司是做智慧交通的,主要卖交通相关的硬件产品和软件平台
- 硬件主要是路口或路段上的前端硬件设备,包括信号机、雷达、雷视、边缘计算单元等,软件包括信控平台、智慧路口、管控平台等
- 信号机通信协议有国标推荐协议,定义了一些接口和数据字段,现在信号机厂商常用的有国标2007和国标2017,这也是信号机送检需要遵守的协议
- 一般经过检验、进入市场的信号机,至少都已经实现了国标2007协议,当然,由于要创造通信壁垒,防止自家的信号机被别的信控平台轻松接入,各家对协议的细节都有不同的实现
- 当然,这也是因为国标协议没有定义这些细节,因此统一信控很难实现,除非是不做信号机硬件只做平台的大厂商去推动
- 硬件也有配套的软件,硬件里一般使用的是嵌入式编程,使用精简的Linux系统,配套软件基本使用C语言编写
- 当我们的信号机配置工具或者信控平台,需要与信号机进行通信时,遵循约定好的通信协议,进行代码开发,使用socket进行通信接收和传输二进制数据
- 在做智慧路口的开发时,接收智慧路口的硬件边缘计算单元的数据,使用的也是socket通信协议,根据事先定义的协议,订阅和接收解析数据
心跳与连接
- 对于平台软件与硬件的socket通信,要特别注意网络的断开与重连,因为在现实网络环境中,即使是内网,网络波动也无法避免
- 维护好socket通信,处理好连接断开与重连,才能做好这个通信服务
- 可以通过心跳来保持连接,例如10秒发起一次心跳请求,连续3次没有心跳应答,就认为离线,进行离线情况的处理和尝试重连
- 但是不能只用心跳,数据通信也算,如果心跳没有应答,但是有数据过来了,这个时候应该也认定是连接正常的(可能是应答信息被海量信息淹没,黏包拆包没处理好,丢掉了)
- 对于主动断开socket连接,一定要慎重,不仅要有心跳次数校验,也要有数据通信对心跳监测的重置
- 有时候,糟糕的心跳检测主动断开操作,还不如没有检测
报错与捕获
- 我们的socket通信都是传输的都是二进制数据,而且都是把数据类型转换成数字,只传输数字类型数据
- 对于socket通信,最需要注意的就是黏包和拆包问题了,如果没有进行处理,通信并发比较高时,就好导致比较多的解析错误,只能丢掉数据
- 而且,如果你的报错没处理好,一报错直接就把连接断开了,那就更致命了。在公司联调测试都没问题(少量数据包),一旦部署到生成环境,直接频繁报错重连(大量数据黏包解析报错),直接爆炸
- 网络连接不稳,数据包丢失,数据不完整,也会解析报错,都有可能
- 数据不完整,解析会报错,所以一定要处理黏包,要捕获报错,不能一报错就断开连接了
- 处理黏包拆包的可以参考我这篇博客:关于Netty使用中黏包拆包带来报错问题及解决
- 如果不是Java语言,或者未使用netty,也可以参考使用里面的思路
- 简单陈述下思路:
- 先检验数据报文头,如果不是,丢弃
- 读到报文头后,插好标记点(报文头前),开始解析处理数据
- 读取报文头里的数据长度值(一般报文头里都有一个字节表示数据体长度),再获取剩余数据报文体包字节长度,如果小于报文体长度值,重置游标到前面的标记点,结束等待下一个报文来临
- 如果长度大于等于报文体长度值,按照协议继续解析长度内的报文体,解析完返回,剩下的字节(应该是报文头或者加上一部分数据体),下次再继续解析
文章来源地址https://www.toymoban.com/news/detail-686502.html
文章来源:https://www.toymoban.com/news/detail-686502.html
到了这里,关于网络编程socket慎重断开连接的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!