私はWCFの周りのロープを学んでいます。私が計画していたのは、NetTcpBindingを使用してクライアントとサーバー間で二重チャネルを開き、サーバーがクライアントへの要求を開始できるように、それを無期限に開いたままにすることでした。
それから私はJesseEzellによるこのブログに出くわしました。これは、障害をキャッチできないため、チャネルを無期限に開いたままにしておくのは悪いことであり、あらゆる種類の不安定性を引き起こすことを示しているようです。
あれは正しいですか？NetTcpBindingを使用して、関係のいずれかの側で開いているチャネルへの参照を保持している場合、通信障害が発生するとどうなりますか？失敗イベントをキャッチするにはどうすればよいですか？他にどんな落とし穴がありますか？使用している.NETFrameworkに違いはありますか？（私は4.0を使用しています。）
私はジェシーに同意しません（補足として：彼はまた、デフォルトでWCFサービスクラスをシングルトンとして使用することを推奨しています。これは私の意見ではこれまでで最悪のアイデアです）....
サーバーで例外をキャッチすることに十分注意している限り（たとえばIErrorHandler、サービスクラスにインターフェイスを実装することによって）、チャネルをシャットダウンし続ける意味はありません...特にnetTcpBindingを使用する企業LAN環境ではそうではありません。
たとえば、ライセンス費用が発生することが多いデータベース接続とは異なり、サービスマシンへのネットワーク接続を開いたままにしておくと、問題が発生することはありません。また、通常は限られたリソースではないため、常に開いたり閉じたりすることは無意味に思えます。
サービスチャネルを長期間開いたままにする場合は、クライアント側で障害を処理できる必要があります。たとえば、例外が発生した場合に、チャネルに障害が発生した状況から回復できる必要があります。結局のところ発生しました（たとえば、ネットワークがダウンしているなど）。
しかし、そうすると、すべての呼び出しの後にチャネルを絶えず閉じて、次の呼び出しのために再開することに何のメリットもありません...
はい、チャネルが不要になったらすぐに閉じることをお勧めします。ただし、二重通信の場合は通常ではありません。二重通信を使用している場合、サーバーがクライアントにメッセージを送り返すことができるように、チャネルを開く必要があります。WCF通信は、常にクライアントによって開始されます。コールバックは、クライアントによって開始されたチャネルを開いたままにすることによってのみ許可されます。
二重通信には、接続障害を処理するためのいくつかの追加タスクが含まれます。クライアントが定期的に接続を確認できるように、サービスにはpingメカニズムが含まれている必要があります。接続に失敗した場合、クライアントは例外を受け取り、接続を再確立できるようになります。また、サービスは、障害が発生したチャネルにコールバックメッセージを送信するときに例外を処理する必要があります。