保持 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 不做任何明示或默示的保證。