I am developing a WCF application. In the app.config file, I am using reliableSession enabled. And my sendTimeOut of the binding is set to 10 mins. While testing the application, I am getting one issue, like I am disconnecting the network, and I am trying to connect to remote system, as I am enabled reliableSession,proxy it is waiting for 10 mins, then only throwing exception. Is there any attribute / property, which will help me to detect network connection available in the app.config file or as part of reliable session?

クライアントへのコールバックを使用するWCFサービスを作成しようとしています。接続（インターネット、ネットワーク）があり、クライアントまたはチャネルのいずれかがチャネルを明示的に閉じていない限り、チャネルを開いたままにしておく必要があります。

チャネルを開いたままにするために（アクティビティがなくても）、WCFがサポートする信頼できるセッションを見つけました。信頼できるセッションを使用することにより、考慮に入れる必要のある2つのタイマーがあります。Binding.ReceiveTimeoutとReliableSession.InactivityTimeout。

インターネットで検索した後も、この2つがどのように連携しているかを正確に理解することはできません。2つのいずれかがタイムアウトすると、接続に障害が発生した状態になることを私は知っています。

私の最初の質問：信頼できるセッションが有効になると、正確にはどうなりますか？

私の2番目の質問：ここで、msdnが次のように言うのはなぜですか？

いずれかの非アクティブタイマーが起動すると接続が切断されるため、ReceiveTimeoutより大きくなるとInactivityTimeoutを増やしても効果はありません。これらのタイムアウトの両方のデフォルトは10分であるため、信頼できるセッションを使用する場合は、違いを生むために常に両方を増やす必要があります。

Windows ストア アプリで WCF の信頼できるセッションを使用することは可能ですか?

C# を使用して、Visual Studio 2012 Professional で Windows ストア アプリを作成しています。セッションを使用して WCF サービスにアクセスしようとしています。Windows ストア アプリでサポートされていないため、WSHttpBinding を使用できません。Windows ストア アプリは、信頼できるセッションをサポートする NetHTTPBinding をサポートしていることがわかりましたが、バインディングの ReliableSession プロパティにアクセスできないようです。また、"bool trustedSessionEnabled" をパラメーターとして受け取るコンストラクターにもアクセスできません。

Windows ストア アプリのセッションをサポートするバインディングはありますか?

-ジョー

サーバーの CPU 負荷が高い場合、またはスレッド プールがビジー状態の場合の WCF Reliable Sessions の障害

サーバーの CPU 負荷が高い (80 ～ 100% の範囲) 場合、または使用可能な即時 IO スレッドプール スレッドがない場合に、インフラストラクチャ キープアライブ メッセージの発行または受け入れを妨げる WCF Reliable Sessions に設計上の欠陥があるようです。メッセージを処理します。この症状は、信頼できるセッションの非アクティブ タイムアウトが原因で明らかにランダムなチャネルが異常終了することとして現れます。ただし、キープアライブ タイマーが実行できないにもかかわらず、アボート タイマーが起動しているように見えるため、アボート ロジックはより高い優先度で、または別のメカニズムを介して実行されているようです。

参照元を掘り下げると、ChannelReliableSession は InterruptableTimer クラスを使用して inactivityTimer を処理しているようです。応答として、ReliableOutputSessionChannel によって設定された PollingCallback を起動し、ACKRequestedMessage を作成してリモート エンドポイントに送信します。InactivityTimer は、WCF 内部の IOThreadTimer/IOThreadScheduler を使用して、それ自体をスケジュールします。これは、タイマーを処理するために使用可能な (ビジーでない) IO ThreadPool スレッドに依存します。CPU 負荷が高い場合、スレッド プールは新しいスレッドを生成しないようです。その結果、複数のスレッドが実行されている場合 (私の 4 コア マシンでは 8 スレッドのように見えます。15 秒の inactivityTimeout で 7 は中止されて失敗します)、キープアライブを送信するスレッドは使用できません。ただし、クライアントの信頼できるセッションの非アクティブ タイムアウトをサーバーよりも長くなるように変更すると、これらの条件下でもサーバーはメッセージをより短い時間で期待しているため、一方的にチャネルを中止します。そのため、中止ロジックがより高い優先度で実行されているか、実行中のスレッドの 1 つに例外がスローされているようです (どれかは不明)。CPU の使用率が高いためにサーバーでの中止が遅れ、クライアントの長いタイムアウトが最終的にヒットすることを期待していましたが、そうではありませんでした。CPU 負荷が低い場合、これとまったく同じシナリオが、返されるまでに 30 ～ 90 秒かかる同時呼び出しでも完全に正常に機能します。

InstanceMode が何であるか、最大同時接続、セッション、またはインスタンスが何であるか、他のタイムアウト値が何であるかは関係ありません (recieveTimeout 以外は inactivityTimeout より大きくなければなりません)。これは完全に WCF 実装の設計上の欠陥です。偽のアボートが生成されないように、分離された優先度の高いスレッドまたはリアルタイム スレッドを使用してキープアライブ メッセージを処理する必要があります。

短いバージョンは次のとおりです。CPU負荷が低いままである限り、15秒の信頼できるセッション非アクティブタイムアウトで完了するのに60秒かかる1000の同時リクエストを問題なく発行できます。CPU負荷が高くなるとすぐに、呼び出しはランダムにこれには、CPU 時間をまったく消費していない呼び出しや、使用されるのを待っているアイドリング状態のデュプレックス セッションが含まれます。受信呼び出しも CPU 負荷に追加されると、他の要求が受信キューに留まっている間、中断が保証された要求で実行時間が浪費されるため、サービスは死のスパイラルに入ります。サービスは、すべての要求が停止され、進行中のすべてのスレッドが終了し、CPU 負荷が低下するまで、正常な状態に戻ることはできません。この動作は、逆説的に Reliable Sessions を最も信頼性の低い通信メカニズムの 1 つにしているように見えます。

これと同じ動作がクライアントにも当てはまります。その場合、WCF クライアントはボックス上の他のプロセスに翻弄される可能性がありますが、CPU 負荷が高い場合、すべての操作が inactivityTimeout 未満で完了しない限り、信頼できるセッションをランダムに中止します。ただし、新しい呼び出しを発行しない場合すぐに、WCF は引き続きキープアライブの送信に失敗し、チャネルに障害が発生する可能性があります。

一部のサーバーに 4.5 ランタイムをインストールした後、多くの winsock 関連のエラーが発生しました。.Net 4.5 ランタイムで ReliableSessions を使用して WCF を使用している場合 (4.0 では再現できません)、\Device\Afd へのハンドル リークまで問題を追跡しました。

問題を特定/証明するためのテストプログラムを作成しました。

かなりダミーの WCF サービスとクライアント (VS から生成される可能性がある) を想定します。

そしてそれはホスティングと消費です。

テスト プログラムの出力は次のとおりです。

備考：

• Close() がスローされる可能性があるため、より適切なエラー処理を行う必要があることはわかっていますが、この場合はスローされないため、ここに貼り付けるコードを減らすことを好みました。
• ここでは、(\Device\Afd だけでなく) すべてのハンドルのハンドル数をログに記録します。これにより、すばやくテストしやすくなりますが、sysinternals の handle.exe で多くのチェックを行い、ハンドルの名前/タイプを確認しました。
• ハンドルは、サービスではなくクライアントによってリークされます (少なくとも、サービスホストを閉じた後に適切にクリーンアップされます)。

バリエーション:

• Proxy.Close() を Abort() に変更すると、すべてのハンドルが適切に解放されます (ただし、予想どおり、サービスを閉じるのは困難です)。
• でチャネルを作成してIClientChannel proxy = ChannelFactory<IMyService>.CreateChannel(binding, address) as IClientChannelも同じ結果が得られます
• channelfactory インスタンスを介してチャネルを作成すると、ハンドルが適切に解放されます。IClientChannel proxy = new ChannelFactory<IMyService>(binding, address).CreateChannel() as IClientChannel
• ClientBase<>.CacheSetting を AlwaysOn に設定すると、問題は解決しますが、常に可能とは限りません。

このプログラムがハンドルをリークしている理由を誰か知っていますか?

簡単に言えば、私の間違いでなければ、パッケージが順番に送信されることを確認したいときにセッションが使用され、セッションを使用できるようにするには信頼できる接続が必要です。

しかし、どのような種類のアプリケーションがそれを必要とするのでしょうか? 私の場合、クライアントがデータベースからサービス データに要求する単純なアプリケーションです。サービスはデータベースからデータを取得し、結果をクライアントに送信します。また、クライアントは、データベースからのデータの追加、変更、または削除を要求できます。この場合、信頼できる接続とセッションが必要かどうか?

ありがとう。

クライアント側の「順序付き」フラグの機能は理解していますが、サーバー側の構成は何かをしますか? 「注文済み」フラグが「true」または「false」に設定されているかどうかに関係なく、通信が機能することはわかっています。サーバー側の冗長設定ですか？