vxworks系统DCOM库修改

一直困扰的一个问题,
当开发OPC程序时候(OPC使用DCOM作为基础通讯组件),如果vxworks突然断线或者系统崩溃,
如果想再次连接windows端的OPCServer, 或者windows端的OPCClient想再次连接vxworks的OPCServer,
结果都会连不上,基本上要等很长时间,至少6,7分钟以上,才能让你重连成功。
作为一个产品,系统崩溃或者网络断线这种非正常关闭,是不可避免的,
而要等这么长时间才能让你重连,实在是无法忍受的事情。

这个问题是 vxworks5。5下自带的DCOM一直都有的问题, 我不清楚高版本的vxworks有没解决这个的问题。
因为各方面的原因,一直使用的是5。5的vxworks系统。
只好研究DCOM协议的实现原理以及vxworks的DCOM源代码来解决问题。
通过windows上用Ethernet抓包分析,发现windows通过135端口请求vxworks的DCOM对象时候,
vxworks总返回一个固定端口,
于是找到vxworks的DCOM代码,把这个端口改成随机值,
可改好之后,问题依然存在,再次抓包分析, 发现vxworks虽然这次能返回不同的端口,
但是当断线重连,windows端的DCOM请求的依然是之前的端口,怎么会这样呢?
再多次抓包,多次研究DCOM协议,以及多次通过实验抓包分析两个windows端的DOCM通讯数据。
渐渐的,有个关键的东西引入眼帘:OXID。
于是赶紧google搜索 OXID究竟是怎么回事。
原来是DCOM对象的唯一标志,8个字节大小,DCOM依靠它来唯一标志DCOM对象。
DCOM有OXID解析器,缓存oxid和DCOM对象信息的绑定,
抓包分析,每次vxworks崩溃重连居然都返回同一个oxid值,
而windows端的DCOM自然通过这个值查找本地缓存的DCOM信息,
用先前缓存的信息来连接vxworks端的DCOM,这样能连的上才怪。
这个缓存超时时间挺长的,大概6,7 分钟的样子。
知道问题所在,赶紧查看vxworks的DCOM源代码,果然,
它使用自己的IP地址来初始化OXID,因为我们设置的都是固定IP,所以每次都返回一样的OXID了。
找到这个BUG,修改成随机值,
问题得到解决, 现在随便怎么搞,OPC都能相当顺利的重连,
很高兴能解决这么一个困扰很久的问题。

你可能感兴趣的:(C++,C++,vxworks,DCOM,vxworks)