欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

GB28181设备目录查询问题案例分析

程序员文章站 2022-07-05 23:15:49
...

在GB28181协议中,规定<CmdType>Catalog</CmdType>为设备目录查询,用于获取下级设备通道,包括下级通道厂商,状态等信息。

(1)请求消息示例:(注意这里的SN,DeviceID为下级设备或者平台的ID)

GB28181设备目录查询问题案例分析

(2)响应消息示例:

响应消息中,对应的SN为请求消息中的SN,达到请求和响应一一关联的目的。

SumNum:这里表示本次响应通道总数,Num表示单个响应携带通道数量。所以,大部分平台这里会计算多个MESSAGE响应中的通道数量(Num)与SumNum做对比。当两者一致时,表示本次目录查询请求完成。(注:响应消息中的其他字段含义,详见《GBT28181-2016》)

GB28181设备目录查询问题案例分析

问题案例分析:

问题一:响应消息被网关丢弃

上下级平台级联,下级存在50万设备。在上级检索下级设备目录时,下级平台抓包,已经收到上级平台的查询消息,且已经发出响应消息。但上级平台未收到下级平台响应,导致目录检索失败。

原因分析:在基于多设备(超10万)平台级联的应用过程中,目录查询被广泛应用于同步上下级通道状态。这就要求上级定时或者手动检索下级设备。在大量设备的情况下,下级推送设备目录时,对应DeviceList中的Num会变成20,30。即:一个MESSAGE消息响应中,带多个通道。如下图所示:

GB28181设备目录查询问题案例分析

这种情况,会导致以下2个问题:

(1)单个数据包超出最大UDP消息长度;

(2)存在网关的情况下,网关会直接丢弃大的数据包。这在对数据要求性能比较高的网络环境中,会经常出现。

问题二:无法判断设备目录查询结束

(1)某厂家推送设备目录时,长期缺少通道。如:SumNum为15,而实际只推送了在线的7个通道。这个时候无法使用计数统计的方式判断本次查询已经完成。

(2)由于国标编码具有本域下唯一的特性,部分服务器会丢弃重复的编码,这也会导致计数和SumNum不一致,无法判断查询已经结束。

解决方案:

针对查询的SN建立开始时间,每次收到一个响应,更新这个时间。在下级或者设备未正确推送的情况下,超过60秒未收到设备响应,即认为本次查询已经完成。

问题三:(TCP接入时)查询目录导致本机断网

上下级级联时,基于TCP存在大量TCP拉流,同时目录查询时,突然出现本机断网的情况。无法ping通127.0.0.1,观察网络带宽和CPU性能,都处于正常范围。

分析思路:

(1)网络分析:iftop –N –n –l ,网络带宽富余,未超出限制;

(2)句柄分析:losf | wc –l 系统各句柄正常,未超出限制;

(3)其他:cpu等,此处不详细解析。

后通过分析排查,发现arp表溢出。linux系统默认大小为1024。查看当前占用:arp -a | wc –l 每次达到1024 之后,出现断网的情况。

解决方案:

(1)调整内核参数:vi /etc/sysctl.conf  增加或修改如下项目:

net.ipv4.neigh.default.gc_thresh1 = 512
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 10240

(2)执行更新配置:sysctl -p