保持 DCOM 的心跳

文档版本

编写目的：

    本文档将说明 DCOM 的心跳给编程上的影响 。

概述

排除了代码错误的可能性后，联想到 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 错误。

更多信息

我的 Server 如何判断 Client 是否在运行中？

DCOM 设计时就预先要考虑能处理任何形式的 Server 、 Client 或者 Network 崩溃的组合。所以 DCOM 决定在 Client 和 Server 之间保持一个背景“ ping ”。如果 Client 的连接丢失， NT 将在 6 分钟之内检测到。这时，服务器故意模拟 Client 的正常断开情形，将 Client 从 Server 请求的所有接口的引用计数统统释放。

正因为如此，编写 Server 的程序员不必要太过于担心 Client 的意外崩溃。 NT 将会从根本上保证 Client 正常断开并释放所有引用的接口。

当一个 Connection 被请求建立之后， DCOM 将在三次不成功的 ping 之后，认定本次连接超时。由于这些 ping 每隔 2 分钟发送一次，所以 6 分钟就是这么计算出来的。

总结：

u       Pinging 是一种检测客户端是否异常终止的著名手段

u       一般在服务器端的设计中，每一个输出的对象都有一个 pingPeriodTime 参数，和一个 numPingsToTimeout 参数

u       如果 pingPeriod 时间过去，而并未接收到来自于 Client 的 ping ，所有对接口的远程引用计数，将被认为失效，从而可以被垃圾回收器收回。

前面说的0x80010108问题解决办法就是每隔半分钟就给服务器发送一个无害的消息，保证connection不被断掉。

本文档所包含的信息代表了在发布之日， ZhengYun 对所讨论问题的当前看法， Zhengyun 不保证所给信息在发布之日以后的准确性。

本文档仅供参考。对本文档中的信息， Zhengyun 不做任何明示或默示的保证。