GB28181设备目录查询问题案例分析
在GB28181协议中,规定<CmdType>Catalog</CmdType>为设备目录查询,用于获取下级设备通道,包括下级通道厂商,状态等信息。
(1)请求消息示例:(注意这里的SN,DeviceID为下级设备或者平台的ID)
(2)响应消息示例:
响应消息中,对应的SN为请求消息中的SN,达到请求和响应一一关联的目的。
SumNum:这里表示本次响应通道总数,Num表示单个响应携带通道数量。所以,大部分平台这里会计算多个MESSAGE响应中的通道数量(Num)与SumNum做对比。当两者一致时,表示本次目录查询请求完成。(注:响应消息中的其他字段含义,详见《GBT28181-2016》)
问题案例分析:
问题一:响应消息被网关丢弃
上下级平台级联,下级存在50万设备。在上级检索下级设备目录时,下级平台抓包,已经收到上级平台的查询消息,且已经发出响应消息。但上级平台未收到下级平台响应,导致目录检索失败。
原因分析:在基于多设备(超10万)平台级联的应用过程中,目录查询被广泛应用于同步上下级通道状态。这就要求上级定时或者手动检索下级设备。在大量设备的情况下,下级推送设备目录时,对应DeviceList中的Num会变成20,30。即:一个MESSAGE消息响应中,带多个通道。如下图所示:
这种情况,会导致以下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
上一篇: iOS设计模式—工厂模式