私はWCFの周りのロープを学んでいます。私がしようとしていたのは、NetTcpBindingを使ってクライアントとサーバーの間にデュプレックスチャネルを開き、サーバーをクライアントに要求できるように無期限に開いておくことでした。WCF - 長時間チャンネルを開いたままにするのは悪い習慣ですか？
次に、私はこの不具合をキャッチできず、すべてのやり方で不安定になるので、チャンネルを無期限に開いておくのが悪いことを示すように見えます。
これは間違いありませんか？ NetTcpBindingを使用してリレーションシップのいずれかの側のオープンチャネルへの参照を保持すると、通信に失敗した場合はどうなりますか？失敗イベントをどのようにキャッチしますか？他に何があるの？ .NETフレームワークで使用している違いはありますか？ （4.0になっています）
私はジェシーと（サイドノートとしてを：彼はまた、あなたが私の意見で史上最悪のアイデアです、デフォルトでシングルトンとしてWCFサービスクラスを使用することをお勧めします）に同意していない.....
サービスクラスにIErrorHandlerインターフェイスを実装するなど、サーバー上で例外を捕捉するのに十分注意している限り、特にnetTcpBindingを使用している企業LAN環境ではチャンネルをシャットダウンする必要はありません。
ライセンスコストを払うデータベース接続、サービスマシンへのネットワーク接続を開いたままで問題が発生してはいけません。また、通常は限られたリソースではないため、常に開いたり閉じたりするのは無意味です。
サービスチャネルを長時間開いたままにしておくと、クライアント側で障害を処理できるようにする必要があります。チャンネルに障害が発生した場合、例外が発生した後（ネットワークがダウンしているなど）に復旧できなければなりません。
しかし、そうすると、毎回通話後にチャンネルを閉鎖してから次の時間に再開すると何のメリットもありません。
はい、チャンネルがもう必要なくなったらすぐに閉じることをおすすめします。しかし、デュプレックス通信の場合は通常ではありません。デュプレックス通信を使用している場合は、サーバーからクライアントにメッセージを返すことができるように、開かれたチャネルが必要です。 WCF通信は常にクライアントによって開始されます。コールバックは、クライアントによって開始されたチャネルをオープンに保つことによってのみ許可されます。
デュプレックス通信には、接続障害を処理するための追加のタスクが必要です。あなたのサービスには、定期的な間隔でクライアントが接続を確認できるように、何らかのpingメカニズムが含まれている必要があります。接続に失敗した場合、クライアントは例外を受け取り、接続を再確立することができます。また、障害の発生したチャネルにコールバックメッセージを送信するときに、サービスが例外を処理する必要があります。