デュプレックスバインディングWCFアプリケーションでドロップされたクライアントを処理する

Question

WCFアプリケーションでは、Microsoftサンプルのほとんどに続くサブサブモデルを使用しています。Design Patterns: List-Based Publish-Subscribe。

サービスでsubscribe()とunsubscribe()という概念が提供されていますが、クライアントが死んだ場合やチャネルに障害が発生した場合のクリーンアップを処理するベストプラクティスは何ですか？現在、私は現在InstanceContextのClosedとFaultedイベント（サービス利用者PerSessionインスタンスコンテキストモードとnetTcpBinding）にハンドラに接続したときに、クライアントが加入：

_communicationObject = OperationContext.Current.InstanceContext; 
_communicationObject.Closed += OnClientLost; 
_communicationObject.Faulted += OnClientLost; 

はOnClientLostハンドラは、単にしかし、クライアントをスクライブ解除します：

1. クライアントがデュプレックス通信を切断したときのすべての状況を把握するのに適していますか？サービスは、クライアントと通信してクリーンアップを処理しようとした時点で発生した例外を処理するだけですか？
2. クライアントのコールバックハンドラの登録を解除するだけでなく、特に障害が発生した場合にはさらにクリーンアップを行う必要がありますか？

This questionは、同様の質問を提起したが、最終的にサブスクライブおよび/またはそれらのイベントの処理

おかげ

Answer 1

コールバックチャネルのClosedおよびFaultedイベントにハンドラをアタッチしてから、コールバックがサーバによって呼び出される直前の時点でクライアントを強制終了しました。各試行で、サーバーがコールバックを呼び出そうとする前に、Closed/Faultedイベントが瞬時に発生しました。クライアントチャネルの破棄は、別のスレッドがコールバックに入っているときと同じように発生する可能性があるため、try-catchブロックでコールバック呼び出しをラップしています。

唯一のクリーンアップは、コールバックチャネルへの参照を削除することでした。 WCFとガベージコレクタが残りの処理を行います。

Answer 2

を解除呼び出すクライアントの外ケースに答えを提供していません同期加入者のリストを維持します。それは確かに十分に丈夫です。メッセージの送信中にクライアントがドロップした場合、イベントが発生する前に例外が発生する可能性があるので、イベントをクリーンアップできるように無視する準備ができていることを覚えておいてください。

サブスクライバリストからクライアントを削除することを除いて、追加のクリーンアップはアプリケーションに完全に依存します（つまり、クライアントの接続時に取得したリソースを解放する）。私は、必要な他のクリーンアップについて認識していません。