保持 DCOM 的心跳

?

文檔版本

編寫目的：

??? 本文檔將說(shuō)明 DCOM 的心跳給編程上的影響 。

概述

排除了代碼錯(cuò)誤的可能性后，聯(lián)想到 COM+ 的一個(gè)特性：保持心跳。 COM+ 為了實(shí)現(xiàn) JIT( 即時(shí)激活 ) ，必須每隔一段時(shí)間讓 COM+ 組件的實(shí)例和調(diào)用方之間保持一個(gè)心跳，告訴調(diào)用方，我還活著。以前沒(méi)有想過(guò)它為什么要定期發(fā)送一次消息，通知對(duì)方自己健在呢？也許這是一種規(guī)則，如果不這么做的話，一定會(huì)有大麻煩。

那么是 DCOM 協(xié)議的制約了？

我們從新聞組中得到了一個(gè)模糊的說(shuō)明：

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 ，看樣子我們的方向是正確的。確實(shí)存在一個(gè)約定的時(shí)間間隔： 6 分鐘。我們?cè)噲D描述我們得到的第一個(gè)概念： 6 分鐘內(nèi)，服務(wù)器端沒(méi)有得到來(lái)自于客戶端的消息，就默認(rèn)客戶端已經(jīng)消失，于是斷開連接。所以我們這之后的再次調(diào)用，就會(huì)得到 0x80010108 的 COM 錯(cuò)誤。

更多信息

我的 Server 如何判斷 Client 是否在運(yùn)行中？

DCOM 設(shè)計(jì)時(shí)就預(yù)先要考慮能處理任何形式的 Server 、 Client 或者 Network 崩潰的組合。所以 DCOM 決定在 Client 和 Server 之間保持一個(gè)背景“ ping ”。如果 Client 的連接丟失， NT 將在 6 分鐘之內(nèi)檢測(cè)到。這時(shí)，服務(wù)器故意模擬 Client 的正常斷開情形，將 Client 從 Server 請(qǐng)求的所有接口的引用計(jì)數(shù)統(tǒng)統(tǒng)釋放。

正因?yàn)槿绱耍帉? Server 的程序員不必要太過(guò)于擔(dān)心 Client 的意外崩潰。 NT 將會(huì)從根本上保證 Client 正常斷開并釋放所有引用的接口。

當(dāng)一個(gè) Connection 被請(qǐng)求建立之后， DCOM 將在三次不成功的 ping 之后，認(rèn)定本次連接超時(shí)。由于這些 ping 每隔 2 分鐘發(fā)送一次，所以 6 分鐘就是這么計(jì)算出來(lái)的。

總結(jié)：

u ????? Pinging 是一種檢測(cè)客戶端是否異常終止的著名手段

u ????? 一般在服務(wù)器端的設(shè)計(jì)中，每一個(gè)輸出的對(duì)象都有一個(gè) pingPeriodTime 參數(shù)，和一個(gè) numPingsToTimeout 參數(shù)

u ????? 如果 pingPeriod 時(shí)間過(guò)去，而并未接收到來(lái)自于 Client 的 ping ，所有對(duì)接口的遠(yuǎn)程引用計(jì)數(shù)，將被認(rèn)為失效，從而可以被垃圾回收器收回。

前面說(shuō)的0x80010108問(wèn)題解決辦法就是每隔半分鐘就給服務(wù)器發(fā)送一個(gè)無(wú)害的消息，保證connection不被斷掉。

?

本文檔所包含的信息代表了在發(fā)布之日， ZhengYun 對(duì)所討論問(wèn)題的當(dāng)前看法， Zhengyun 不保證所給信息在發(fā)布之日以后的準(zhǔn)確性。

本文檔僅供參考。對(duì)本文檔中的信息， Zhengyun 不做任何明示或默示的保證。