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都能相当顺利的重连，
很高兴能解决这么一个困扰很久的问题。