c# - netnamedpipebinding 無限 receiveTimeout はどの程度信頼できますか?

Question

サービスとクライアント間の一貫した名前付きパイプ接続に依存する二重 WCF サービスがあります。これは、クライアントがサービスで Subscribe を呼び出し、サブスクリプション リストに登録される、一種のパ​​ブリッシュ/サブスクライブ システムです。次に、サービスは独自の特定の更新メソッドを呼び出し、コールバックを介してクライアントに更新をプッシュします。

netnamedpipebinding の recieveTimeout を「無限」に設定しました。この接続が永久に開いていることを合理的に信頼できますか? さらに重要なことは、タイムアウト以外でチャネルに障害が発生する状況はありますか?

名前付きパイプは単なる共有メモリの場所であるため、ハードウェアの問題以外に一貫して失敗する理由はあまり考えられません。さらに、一定の間隔で ping を実行する以外に接続を保証する方法はほとんどありません。

余談ですが、クライアントを WCF サービスにすることも避けたいというのが私の直感です。私はそれが本当の循環依存ではないことを知っていますが、気分が悪いだけです. しかし、私は偏執的であるだけで、そのようなパターンは大丈夫だと言う人にはオープンです.

Answer 1

接続に頼ることはできません。サービスで単一の未処理の例外/障害が発生すると、チャネルが閉じられます。クライアントで Closed イベントと Faulted イベントを処理するか、プロキシの再作成と再サブスクリプションを使用して ping メカニズムを実装する必要があると思います。

二重通信を使用する場合、クライアントがコントラクトを公開する必要があるだけです。クライアントはエンドポイントを公開しないため、サービスを公開することとは異なります。名前付きパイプは設計上二重化されているため、通信はクライアントからサービスに作成された単一のチャネルによって実行されます。何らかのトランスポートを介して二重通信を行いたい場合は常に、クライアントで何らかの処理コードが必要になります。