DZ先生怪谈国标案例14——你真的订阅成功了吗？

1.自述
今天DZ先生主讲的课题是“你真的订阅成功了吗？”，2017年，我和海康工程师貌貌先生相识，从此我们结下了缘分，因为在这里，我是他的上级，而他是我的下级，他有两个大平台，一个是X1小区出入口，一个是X2海康平台，且这两个平台的点位不可替代。某天我们的金师傅发现了上下级状态不一致，那一天是我们的烦恼的开始，而且这个问题已经拖了将近快大半年了，直到上周四晚上，终于解决了我们平台和X1小区出入口平台的状态不一致的问题。还剩余一个最大的平台X2待解决中。虽然待解决，但我们已经有了思路，最近我们也会很快将其解决。现在DZ先生用这个案例来谈谈关于这个状态不一致的问题。我们先来看下跟状态同步的订阅流程：

2. 订阅流程

命令流程描述如下:
1: 订阅域向被订阅域发送初始订阅SUBSCRIBE 消息, 订阅目的域的目录变更事件, 消息头域中使用 Event 头域描述订阅事件, 消息体中携带订阅的详细参数, 使用 Expire 头域指定订阅过期时间;
2: 被订阅域设备收到订阅消息后, 向订阅域发送200 OK 响应;
 3: 对于初始订阅操作, 被订阅域立即发送 NOTIFY 消息携带离线及其他异常状态设备目录,消息头域中使用 Event 头域描述订阅事件;
4: 订阅域收到 NOTIFY 消息后回复200 OK 响应;
5: 被订阅域目录变更后, 通过 NOTIFY 消息将变更事件通知订阅域, 消息头域中使用 Event头域描述订阅事件;
6: 订阅域收到 NOTIFY 消息后回复200 OK 响应;
7: 订阅域在过期之前向被订阅域发送刷新订阅 SUBSCRIBE 消息, 订阅目的域的目录变更事件, 消息头域中使用 Event 头域描述订阅事件, 消息体中携带订阅的详细参数, 使用 Expire 头域指定订阅过期时间;
8: 被订阅域设备收到订阅消息后, 向订阅域发送200 OK 响应;
9: 被订阅域目录变更后, 通过 NOTIFY 消息将变更事件通知订阅域, 消息头域中使用 Event
头域描述订阅事件;
10: 订阅域收到 NOTIFY 消息后回复200 OK 响应;
11: 订阅域向被订阅域发送取消订阅SUBSCRIBE 消息, 消息头域中使用 Event 头域描述订阅
事件, 消息体中携带订阅的详细参数,Expire 头域值为0;
12: 被订阅域设备收到订阅消息后, 向订阅域发送200 OK 响应, 取消向订阅域发送目录变更
通知消息。

前期排查问题过程：
根据订阅的流程，订阅成功需要有subscribe和200OK消息。于是我们从开始订阅开始抓包，然后找一个摄像头离线看是否有notify消息，经过多次发现，subscribe和200Ok是有的是没有问题，但notify消息有时候上报有时候不上报。接下来我们又扯到了刷新订阅，为了验证这个问题，我们搭建了测试平台，由于我们的订阅有效期是11天，我们特地抓了11天的报文，发现刷新订阅存在，在这些证据的确凿的情况下，我们认为是下级海康在订阅成功的状态下，设备上下线不发notify消息。

后期排查问题过程：
1. 经过貌貌的多次排查和海康研发的查看，发现了通道关闭，也就是说subscribe订阅成功后，后面的上报notify消息流程没有完毕，导致通道关闭，最终后面下级不在发送notify消息。为了证明正确性，我们查看了rfc 3265文档，文档里是这样解释的

文档下载地址：
链接：https://pan.baidu.com/s/1twq8i5BqPuNXZi-suMNUng
提取码：kz73

我们再来看下报文：


notify消息突然收到487这样的请求终止报文，而不是200Ok，这个时候下级通道被关闭，不会再上报状态变化的notify消息。此时我们需要解决这个报错。
根据这个报错，我们在解决错误问题时发现了以下问题：
1）海康在删除此编码组织后，还会继续发送此notify消息的update事件。后来海康经过数据里里删除后，即解决问题。
2）宇视如果本地没有32这个编码，但是网外推送了32编码，那么下级推送过来时将不会再接收，会认为本地有此编码。
海康貌貌先生把数据里的编码删除后，此时重启服务后，订阅成功，notify消息流程走完，没有一个报错。此时取消一个点位的共享后，进行了notify消息上报。

接下来，我们参照此方法解决和X2平台的订阅问题，发现了另外一个奇葩的问题，DZ先生将在另外一个案例里说明。

总结：
订阅的过程报文是subscribe和200ok，真正成功是notify和200Ok全部走完且没有报错。

DZ先生个人官方微信

***关注DZ君，让监控变得更简单***