保持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 不做任何明示或默示的保证。
Written by zhengyun@tomosoft.com
