二重コールバックの WSDualHttpBinding

Question

二重コールバックに WSDualHttpBinding を使用することは、実際のシナリオでは機能しますか?たとえば、ランダム ポートを使用する .NET アプリケーションがあるとします。サービスはクライアントのベース アドレスとコールバック用のポートを解決できるでしょうか?

Answer 1

あなたの質問に対する完全な答えは、イントラネット シナリオかインターネット シナリオのいずれかの「現実世界のシナリオ」によって異なります。WSDualHttpBinding は両方のシナリオで機能しますが、注意すべき点があります。

イントラネット

WSDualHttpBinding は、イントラネット シナリオで事前構成されたカスタム ポートを使用して .NET アプリケーションと連携し、「はい」サービスはクライアントのベース アドレスとコールバック用のポートを解決できます。正確にその方法は以下で説明されています。以下で説明する理由は、WSDualHttpBinding が主にインターネット上で使用されるように設計されているためです。

クライアントとサーバーの両方で WCF を使用できるイントラネット シナリオでの二重コールバックは、NetTcpBinding または NetNamedPipeBinding を使用するのが最適です。これらのバインディングは、(HTTP ではなく) トランスポートとして TCP と ICP をそれぞれ使用し、カスタム バイナリ エンコーディングを使用するため、両側で WCF が必要です。クライアントへのコールバックの場合、新しいポートを開く必要がなく、バインディング経由でサービスに接続するために使用されたのと同じチャネルが再利用されます。

インターネット

インターネットのシナリオでは、有効な HTTP 要求と応答は一方向にのみ送信され、HTTP は一方向プロトコルとして設計されています。したがって、WSDualHttpBinding を使用する場合、WCF はコールバック用に別の HTTP チャネルを作成します。2 番目の質問に対する答えは次のとおりです。クライアントへのこのコールバックの宛先アドレスは、デフォルトではクライアント マシンのホスト名とポート 80 で構成されます。たとえば、クライアントが開発マシンであり、IIS がインストールされている場合、一部のシナリオではポート 80 が排他的に予約され、プロトタイプ アプリケーションとの競合が発生します。これは何 このブログ投稿 では、その解決策と、ClientBaseAddress プロパティが何を支援するように設計されているかを示します。デフォルトまたはカスタムのどちらのポートを使用するかに関係なく、発信チャネルと個別のコールバック チャネルの両方を確立できるように、両側のすべてのファイアウォールとルーターが正しく構成されていることを確認する必要があります。

.NET アプリケーションは、Silverlight アプリケーションを表すこともあります。ブラウザーで実行されている Silverlight アプリケーションは新しい受信 HTTP 接続を受け入れることができないため、その別個のバック チャネルを使用した WSDualHttpBinding は機能しません。したがって、PollingDuplexHttpBinding は、最初に Silverlight 2 で作成されました。これは、リクエスト チャネルを長時間開いたままにして (ロング ポーリング)、HTTP が一方向であるという事実を回避し、それをバック チャネルとして使用するための賢い「トリック」と考えることができます。クライアントに折り返し電話します。これは、クライアント側とサーバー側の両方に、特にスケーリングに関連する多くの影響を及ぼします。詳細については、を参照してください。 私のブログからのこの投稿.

特定の「現実世界のシナリオ」とユースケースについてのアイデアがあれば、これが二重コールバックに使用する正しいバインディングを見つけるのに役立つことを願っています。

Answer 2

ファイアウォールの背後にあるアプリケーションの場合、理論的にはそうです。それは「現実世界」が何を意味するかによって異なります。これが「高性能」を意味するのであれば、おそらく NetTcpBinding の方が優れたアプローチとなるでしょう。