?
鄧立波 深圳，2007-8
作者聯系方式
:
email:???????? libodeng@gmail.com
msn:?????????? libodeng@gmail.com
tel:???? ???????? 13510275799
版權/著作權所有 (C) 2007 鄧立波 保留所有權利
警告：未經作者許可，任何人或組織不得轉載，公開發布，拷貝，傳播本文獻的全部或部分
?
?
1 問題定義
一般的，我們需要在連接關閉（包括主動或被動關閉）時釋放以下資源：
(1) 一個或多個接收/發送緩存，一個信令緩存（用作拼包，可能一次WSARecv僅收
到半個信令，這時需要一個緩存先保存這半個信令，繼續發出WSARecv 調用，直
到接收到一個完整信令）。
(2) 調用closesocket釋放socket資源。
主要的問題是資源何時釋放，以及該在哪兒釋放。
?
2 緩存如何同socket綁定
方式一
發送緩存綁定到發送操作的OVERLAPPED中（一般通過擴展OVERLAPPED結構添加一個緩存指針變量），接受緩存和信令緩存綁定到接受操作的OVERLAPPED中，如果還有一些資源需要
在IOCP處理發送/接收之外的地方訪問
，你可以再動態分配一個的結構體，將其指針同CompletionKey邦定
方式二
使用一個Hash表，對每個連接定義一個連接上下文，按socket值索引，把一些資源，例如信令緩存指針置于hash中的上下文。
?
方式一優點是速度快（其實也快不了多少），但卻存在資源在哪兒釋放，何時釋放的問題。
對此，網絡上有兩篇文章討論過：
很慚愧，我無法理解前一篇文章中作者所假設的應用環境，因此我無法判定是否這樣真能解決問題，但至少我不放心真的這樣做，即使作者是對的，這種“獨特”的機制也會讓我對服務器的健壯性感到不安。后一文章使用引用計數的方式理論上是可行的，這個引用計數用于跟蹤你所分配的結構體的動態釋放，因此在所有引用到這個結構體的地方都得做引用計數處理（increment reference或者decrement reference），更要命的是上層應用也可能需要對這個結構體保存一個引用（一般是保存結構體的一個指針，即CompletionKey），因為服務器有時需要主動發送數據到client端。這顯然比較麻煩，原本模塊內部的復雜性被擴散到上層代碼。一點疏急就可能就導致資源泄漏或重復釋放，或者訪問已經釋放的資源而發生內存訪問異常，一旦這種bug出現將很難跟蹤調試。作為一個基礎模塊的編寫者，
設計時就要考慮這一點，無論誰寫的代碼，好的結構都可以起到強有力的約束作用，如果不是必要，我建議你不要用這種方式
。最后有一點需要注意的是，如果你沒有資源需要在IOCP處理發送/接收之外的地方訪問，你就不要去分配一個結構體，以免增加額外的麻煩。
?
第二種方式自然更不會遇到重復資源釋放的問題（你可以在任何地方關閉連接，并釋放相關資源），因為你釋放資源時，同時刪除hash表中的連接上下文，所以在釋放之前應該檢查連接上下文是否存在，如果不存在，則表示資源已被釋放。需要注意的是對本次操作的發送/接收緩存應該立刻釋放，同時這些緩存指針不必保存到上下文，而是綁定到相應的OVERLAPPED。這種方式還有一個優點，可以跟蹤所有連接（例如逐一掃描所有連接，處理一些如心跳包之類的事情）。當然你可能擔心hash表畢竟對速度有影響，我們舉個例子，你的IOCP一秒種需要處理10萬個IO，則需要10萬次hash操作，我想說的是 10萬次/一秒的hash其實對現在的CPU是非常輕松的，不用擔心它成為瓶頸。這種方式相對實現非常簡單，出現bug也相對易于跟蹤，對于服務器的設計而言，我一直固執的堅持，穩定性始終是第一的。