10

これまでのところ、デュアル チャネルから取得できる即時の通知を除いて、クライアント ポーリング システムでデュアル チャネルを使用するメリットを実際に提供できる人は誰もいません。他のすべてのポイントは、すぐに通知する必要がない場合、デュアルバインディングが負の価値を提供することを示しています-これに反対する人はいますか?

WSDualHttpBinding を IIS ホステッド サービスで使用する場合と、WCF サービスを呼び出すクライアント ポーリングを使用する場合の利点は、後者でサービスが問題のデータをキャッシュしたと仮定した場合です。

このシナリオは、イベントが発生したときにサービスによってクライアントに通知する必要がある通知タイプのサービス用です。

具体的には、WSDualHttpBinding はポーリングよりもどのような利点がありますか? 例: ネットワーク トラフィックの削減、設計の高速化、保守の容易化、制御の強化 ???

私が理解していることから、WSDualHttpBinding はクライアント ポーリングよりもスケーラブルではありません。編集: Matt が提供したように、タイム クリティカルは二重バインディングの 1 つの理由である可能性があります。

これが私がこれまでに持っているものです：

WSDualHttpBinding

adv: ポーリング タイマーを待たずにすぐに応答を取得できます

dis: WsHttpBinding よりスケーラブルではない

dis: ファイアウォールに優しくない

dis: WSHttpBinding より遅い

コメントに基づいてこれに追加します。間違っていることがあればお知らせください。

入力していただきありがとうございます:-)

4

2 に答える 2

9

この SO スレッドには豊富な情報があります。基本的に、ポーリングには、クライアントが最後のポーリングと同じくらい最新であるという欠点があるため、タイムクリティカルな情報については、ポーリングの頻度を増やす必要があります。各ポーリングはネットワーク リソースを占有し、クライアントにオーバーヘッドを生じさせます。ロング ポーリングや WSDualHttpBinding などのソリューションは、この問題の回避策です。WSDualHttpBinding には、クライアントがエンドポイントをサーバーに公開する必要があるという欠点があります (ファイアウォール環境で問題が発生します)。BOSH/XMPP または別の形式のロング ポーリングも別の方法です。

于 2010-04-26T17:15:56.260 に答える
5

WSDualHttpBinding が作成されたのには理由があります。WCF は、サービスの「コールバック」 (サービスの実行が完了するたびに通知されるクライアントのメソッド) のサポートを提供しました。残念ながら、HTTP は一方向のチャネルであるため、コールバックは許可されません (対照的に、TCP は全二重チャネルであるため、TCPBinding では許可されます)。HTTP の一方向の性質を回避するために、DualHttpBinding が発明されました。2 つの HTTP 接続が同時に開かれ、1 つはサービス要求用で、もう 1 つはコールバック用です。これはスケーラビリティの問題ではなく、必要性の問題です。コールバックを使用する場合 (特にサービスが時間のかかる (実行時間の長い) サービスである場合はコールバックが最適です)、WSDualHttpBinding が最適なオプションです。ポーリングは、すでに指摘されている理由からおそらく最悪です。各ポーリングはネットワーク リソースを占有します。

于 2011-05-21T03:53:15.637 に答える