COM编程---保持DCOM的心跳

                                        保持DCOM的心跳

文档版本 1.0.0114.1
创建时间 2003-1-14
创建人    郑昀
备注 　　第一稿

编写目的：
    本文档将说明DCOM的心跳给编程上的影响。
    概述
    我们的程序员前不久遇到过这样的一个奇怪的现象：
    “服务器端创建出一个ServerA的实例，好几个分布式的客户端持有这个实例的引用，类似于ConnectionPoint的方式。客户端负责向服务器端的实例发送电话拨入、按键、挂机等消息，服务器端负责处理这些消息。但是在生产环境中，每隔一段时间，服务器端调用持有的客户端实例引用时，得到一个COM错误0x80010108，意思是说被调用的对象已与其客户端断开连接。这时客户端却可以调用服务器端的实例，这时候的网络通信质量也很好。实在是看不出来会是什么原因导致这种调用模式周期性出错。程序员报告这个时间大约是7分钟。”
　　COM+的心跳
　　排除了代码错误的可能性后，联想到COM+的一个特性：保持心跳。COM+为了实现JIT(即时激活)，必须每隔一段时间让COM+组件的实例和调用方之间保持一个心跳，告诉调用方，我还活着。以前没有想过它为什么要定期发送一次消息，通知对方自己健在呢？也许这是一种规则，如果不这么做的话，一定会有大麻烦。
　　那么是DCOM协议的制约了？
　　我们从新闻组中得到了一个模糊的说明：
　　After 6 minutes of non usage, the server considers the client disconnected
　　and drops the connection. This is a fixed timeout for DCOM that cannot be
　　changed.
　　Okay，看样子我们的方向是正确的。确实存在一个约定的时间间隔：6分钟。我们试图描述我们得到的第一个概念：6分钟内，服务器端没有得到来自于客户端的消息，就默认客户端已经消失，于是断开连接。所以我们这之后的再次调用，就会得到0x80010108的COM错误。
　　更多信息
　　Question:
　　我的Server如何判断Client是否在运行中？
　　Background:
　　DCOM设计时就预先要考虑能处理任何形式的Server、Client或者Network崩溃的组合。所以DCOM决定在Client和Server之间保持一个背景“ping”。如果Client的连接丢失，NT将在6分钟之内检测到。这时，服务器故意模拟Client的正常断开情形，将Client从Server请求的所有接口的引用计数统统释放。
　　Resolution:
　　正因为如此，编写Server的程序员不必要太过于担心Client的意外崩溃。NT将会从根本上保证Client正常断开并释放所有引用的接口。
　　
　　6分钟是如何计算出来的呢？
　　当一个Connection被请求建立之后，DCOM将在三次不成功的ping之后，认定本次连接超时。由于这些ping每隔2分钟发送一次，所以6分钟就是这么计算出来的。
　　总结：
　　u Pinging是一种检测客户端是否异常终止的著名手段
　　u 一般在服务器端的设计中，每一个输出的对象都有一个pingPeriodTime参数，和一个numPingsToTimeout参数
　　u 如果pingPeriod时间过去，而并未接收到来自于Client的ping，所有对接口的远程引用计数，将被认为失效，从而可以被垃圾回收器收回。
　　前面说的0x80010108问题解决办法就是每隔半分钟就给服务器发送一个无害的消息，保证connection不被断掉。
　　本文档所包含的信息代表了在发布之日，ZhengYun 对所讨论问题的当前看法，Zhengyun 不保证所给信息在发布之日以后的准确性。
　　本文档仅供参考。对本文档中的信息，Zhengyun 不做任何明示或默示的保证。