14

WCF を使用して .Net 3.5 でクライアント/サーバー アプリケーションを開発しています。基本的に、長時間実行されているクライアント サービス (複数のマシン上) は、netTcpBinding を介してサーバーへの二重接続を確立します。次に、サーバーはクライアントのコールバック コントラクトを使用して特定のオンデマンド操作を実行し、クライアントは非同期方式で応答します (かなり標準的なものだと思います)。DuplexClientBase クラスをサブクラス化して、ほとんどの通信を処理します。

残念ながら、いずれかの側で何か問題が発生した場合 (ネットワーク障害、予期しない例外など)、チャネルに障害が発生したり中止されたりして、後続のすべての操作が失敗します。クライアントが障害を起こしたときに自動的にピックアップして操作を再試行する RecoveringClientBase クラスを作成することで、非二重チャネルでのこの制限を回避しました。

私の質問は、デュプレックス チャネルに障害が発生したことを判断する確立された方法はありますか? サーバーまたはクライアントのどこでこれを確認する必要がありますか? それができない場合、接続が再確立されるようにするために必要なオプションは何ですか?

更新:サーバーが障害が発生したコールバック チャネルを使用しようとする可能性がある二重チャネルに固有のアドバイスを探しています。したがって、チャネルに何かが発生したときにすぐに再接続/再サブスクライブするものが必要です。現時点では、チャネルの Closing イベントをリッスンしており、状態が Closed 以外の場合は再作成しています。ある程度は機能しますが、ハッキーに感じます...

4

4 に答える 4

3

長時間のセッション (数分から数時間) でフレークネスを経験しました。それがWCFであるかどうかはわかりませんが、そのネットワークレベルはかなり確信しています。

デュプレックスを完全に廃止することを考えています。接続の状態を管理しようとするのは本当に面倒です。

現在コールバック コントラクトの一部である操作のために、クライアントでサービス エンドポイントをホストすることを考えています。クライアントはエンドポイントの詳細をサーバーに連絡し、サーバーはこれらをどこかに (永続的またはどこにでも) 保存できます。サーバーがクライアントに連絡する必要がある場合、隠しエンドポイントの詳細を介してクライアントへの接続を開きます。基本的に、二重接続を 2 つのクライアント サーバー接続に変換します。

あなたの質問には答えませんが、私はあなたの痛みを感じます。

于 2009-01-09T22:00:32.263 に答える
1

WCF チームの Nicolas Allen は、これについて次のような提案をしています。

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

彼の提案は、これをチャネル レベルで処理することです。チャネル レベルは、カスタム クライアント基本クラスを要求する代わりに、動作を介して任意のバインディングのスタックにプラグインできるため、少し優れています。

于 2008-10-15T14:28:13.987 に答える
0

faulted イベントをリッスンする必要があると思います。クライアント側ではすでに処理していると思いますが、サーバー側は OperationContext.Current.Channel.events です。

コールバック チャネルに障害が発生しており、新しいコールバック チャネルがまだわからないため、メッセージを自動的に再送信する方法が見つかりませんでしたが、クライアントが再接続するまでこれらの呼び出しをサーバーのどこかに保持する必要があります。

クライアントは最終的に障害が発生し、サーバーとのハンドシェイクをやり直す必要があります。これは、サーバーが未送信の呼び出しを送信する必要があるポイントです。

基本的に、障害が発生した/閉じられたチャネルから回復する唯一の方法は、新しいチャネルと交換することですが、最も重要な部分は、実際に切断をオンタイムで検出する必要があることです。信頼できるセッションを有効にすると、ほとんどの時間に障害イベントが発生することがわかりました場合。または、両端でハートビート メッセージを送信して、障害のあるチャネルを「テスト」することもできます。

于 2011-01-18T07:26:17.367 に答える