二重コールバック用のWSDualHttpBinding

Question

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

Answer 1

質問に対する完全な回答は、イントラネットまたはインターネットシナリオの「現実のシナリオ」に依存します。 WSDualHttpBindingは、両方のシナリオで動作しますが、注意すべき仕様があります。

WSDualHttpBindingは、.NETアプリケーションは、イントラネットのシナリオで事前に設定カスタムポートを使用して動作します

イントラネットが「はい」のサービスになりますクライアントのベースアドレスとコールバックのためのポートを解決することができます。以下に説明する理由は、WSDualHttpBindingが主にインターネット上で使用されるように設計されているためです。

クライアントとサーバーの両方でWCFを使用できるイントラネットシナリオでのデュプレックスコールバックは、NetTcpBindingまたはNetNamedPipeBindingを使用すると最も効果的です。これらのバインディングでは、TCPとICPをそれぞれトランスポート（HTTPではなく）とカスタムバイナリエンコーディングとして使用するため、WCFが両サイドで必要になります。クライアントへのコールバックでは、Binding経由でサービスに接続するために使用された同じチャネルが、新しいポートを開かなくても再利用されます。インターネットシナリオの有効なHTTPリクエストとレスポンスで

インターネット

一方向のみに移動する、HTTPは、一方向のプロトコルとして設計されています。したがって、WSDualHttpBinding WCFを使用すると、コールバック用に別個のHTTPチャネルが作成されます。あなたの2番目の質問に答えて：クライアントへのこのコールバックの宛先アドレスは、デフォルトでクライアントマシンのホスト名とポート80で構成されています。たとえば、クライアントが開発マシンで、IISがインストールされている場合、プロトタイプアプリケーションと競合するポート80が一部のシナリオで排他的に予約されます。これは、this blog postが解決策を提示し、ClientBaseAddressプロパティが役立つように設計されているものです。どちらのポート（デフォルトまたはカスタムポート）にかかわらず、発信側チャネルと別個のコールバックチャネルの両方を確立できるように、両方のファイアウォールとルータがすべて正しく設定されていることを確認する必要があります。

.NETアプリケーションは、Silverlightアプリケーションを表すこともできます。ブラウザーで実行されているSilverlightアプリケーションは新しい着信HTTP接続を受け入れることができないため、別のバックチャネルを使用するWSDualHttpBindingは機能しません。したがって、PollingDuplexHttpBindingは、Silverlight 2で最初に作成されました。これは、リクエストチャネルを長時間開いたままにして（長いポーリング）、それをバックチャネルとして使用することで、HTTPが単方向であるという事実を回避する巧妙な「トリック」と考えることができますクライアントにコールバックします。これはスケーリングに特に関係するクライアント側とサーバ側の両方に多くの意味を持ちます。詳細はthis post from my blogを参照してください。

あなたの特定の「現実のシナリオ」とあなたのユースケースを考えれば、これはデュプレックスコールバックに使用する正しいバインディングを練るのに役立ちます。

Answer 2

ファイアウォールの背後にあるアプリケーションの場合は、理論的にはyesです。それはあなたが「現実の世界」の意味に依存します。あなたが "高性能"を意味するならば、たぶんNetTcpBindingはより良いアプラックです。