调测Onvif事件总结解决办法

2021年11月25日 阅读数:2
这篇文章主要向大家介绍调测Onvif事件总结解决办法,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

主要在调测事件用例的过程当中,发现了大量的信息,和不曾碰到的场景和非法错误等信息,先总结解决办法以下:多线程


(1)测试过程当中发现之前的一个难题解决了,原先在生成soap空间命名的文件中有部分须要下载,离线生成则失败,不能打开文件。其实在生成过程当中wsdl增长了导入命名空间的机制,要指定本地离线文件路径便可。但有个注意的地方是,相同扩展名的文件竟然能够自动推导,不用加相对路径,增长反而出错。框架


(2)熟读typemap.dat定义自生成的文件,发现xsd:duration类型文件放开的是类型LONG64,这样致使测试用例时发现client发送的实际时string类型,根本走不通,因此须要屏蔽该类型定义,同时删除duration.c的编译,就会恢复string类型的处理。函数


(3)事件服务功能接口有基本订阅和拉点订阅,还有暂停订阅等管理,这些接口存在相互重合的地方,只能保留一个,不然订阅请求过来,几个服务都会接收并处理,这样就会有多条相应消息回复给客户端,那么客户端会直接报错。测试


(4)Gsoap生成的框架比较死,不能直接使用,须要修改,好比全部客户端的请求消息都是放在header中以request的路径出现,可是框架响应的时候原封不动返回request,其实是须要返回Response,不然客户端会报错。本身封装一个共同接口实现修改返回响应去处理。优化


(5)旧版和新版onvif协议变化很大,有些定义的命名空间网上搜索url都是空白,已经不用了,因此根本通不过,本身追踪查找才发现挪到另外的命名空间地址中了,有的已经合并成新的地址空间,须要去寻找才能对应上,没有可一目了然的地方,须要仔细查找,比较耗时。ui


(6)Onvif里面处理的基本都是utc+0的时间,因此不能直接当本地时间处理,可是设备的time时间系统函数中缺乏mkgmtime的接口,没法直接转换iso8601的utc时间,因此本身封装了个接口单独处理utc时间的转换,比较奏效。url


(7)topic命名空间找不到,没法添加到soap namespace中。spa

实在添加不上名字空间,不过找到了一些信息,就是gsoap名字空间有不同的,有的维护多张映射表nsmap,而后动态选择某个名字空间表,为了不一张表过大,而后也是有动态获取某个名字空间来set名字空间的,和张俊商讨后采用此方法,追加error和topic的名字空间函数放到ServiceContext中做为接口,须要的地方直接ctx->patch_ns加上,结果测试成功。其实客户端也不可能打开每一个名字空间地址去爬虫同样搜索有没有那个信息,也只是验证名字前缀是否包含在xmlns当中,但这只是想一想,后来在w3c协议文档中看到有三个参数设定,就是strict,lax和skip,客户端针对不一样类型会作判别。线程


(8)若是拉点订阅中带有以下信息:
<tev:SubscriptionReference xmlns:tev="http://www.onvif.org/ver10/events/wsdl">xml

<wsa5:Address xmlns:wsa5="http://www.w3.org/2005/08/addressing">http://192.168.5.106:80/onvif/eventing_service?id=urn:uuid:834c5a9a-b936-7965-07d4-8c37214e9c62</wsa5:Address> <wsa5:ReferenceParameters xmlns:wsa5="http://www.w3.org/2005/08/addressing">

<SubscriptionId xmlns="urn:schemas-pelco-com:ws:addressing:1">urn:uuid:834c5a9a-b936-7965-07d4-8c37214e9c62</SubscriptionId>

</wsa5:ReferenceParameters>

</tev:SubscriptionReference>
请记住每一个供应商都不同,因此,须要pullmessage是放到header中,若是有security的认证信息,情报站security信息在header的最后,同时address放到action中,referenceparameters中的subscriptionid直接放到header中。


(9)建立拉点订阅的终止时间响应,到点没有进一步拉取将结束拉点;拉取消息的终止时间一致;拉取支持至少一分钟的超时等待,没有返回空msg,有就返回。单进程单线程处理会阻塞,而拉取消息特殊有个超时等待的过程,很显然不能阻挡其余消息处理,因此单独处理建立线程去处理,如今这种线程处理方式有弊端,虽然建立处理完消息后会释放退出,可是动态建立过多线程自己也是一种资源消耗,目前先实现功能,往后能够优化,好比单线程处理队列方式等。