SignalRとWCFを使用してクライアントにデータをプッシュしますか？
1つのWPFクライアントサーバーアプリケーションがあります。これで、クライアントがサーバーに接続し、サーバーが定期的にデータをクライアントにプッシュするようなシナリオがあります。クライアントへの通知にどのテクノロジーと方法を選択すればよいか、少し混乱しています。
SignalRは私が思うWebアプリケーションに最適で、デスクトップアプリケーションがあります。 WCFサービスを使用すると、二重チャネルとコールバックを介してプッシュ通知を実装できます。では、SignalRまたはWCFサービスを使用するメリットとデメリットを教えてください。
ありがとう
以下は経験からの私の観察です：
SignalRプロ：
- 起動が簡単で、学習曲線が低くなります。ウェブから見つけた例を簡単に実行できます
- 例外処理（接続のドロップ、タイムアウトなど）はAPI内に組み込まれています
SignalRの短所：
- HTTPプロトコルのみをサポート
デュプレックスのメリット：
- HTTPに加えてTCPをサポートします。クライアントの種類がわかっていて、システムが閉じたネットワークで動作している場合、これは深刻なパフォーマンスの向上になる可能性があります。また、TCP HTTPよりも接続の安定性が向上します
二重の短所：
- 学習曲線が高い-起動が難しく、安定したソリューションがあります。確認したいですか？デュプレックスとSignalRサンプルをWebからダウンロードし、互いに正常に実行するために費やす時間を確認します。
- すべての例外的なケース（接続のドロップ、タイムアウトなど）を処理する必要があります
- デュプレックスサービスを長時間使用したいときに、深刻なタイムアウトの問題に直面したのは私だけではないことはわかっています。クライアント接続を維持するために、定期的にサービスコールを行う必要があります。
ちなみに、JavaScript、デスクトップ、SilverlightプロジェクトがSignalRサービスを利用するためのAPIがあります。
SignalRはWebだけではありません。 SignalRサーバー側のコードは、そのクライアントのテクノロジーを気にしません。クライアント側に実装者がいるだけで十分です。
休止データをクライアントに分離する場合は、SignalRを強くお勧めします。この点では、SignalRはWCFよりもはるかに単純であり、WCFに関する問題を共有していて、自分自身がいると思います。簡単なコンソール/ Webアプリケーションのサンプル here を見つけました。
一般的に、Duplex WCFと here のようなCallbackを使用することは私にとって非常に厄介なようです。構成サーバー側がたくさんあるので、SignalRの方が単純だと思います。
さらに、javascriptとObjective-Cで二重（AFAIK）を使用することはできません。
それぞれについて、すでに多くのデータポイントを取得していると思います。ただし、SignalRを選択すると、開発作業よりも多くの利点が得られます。これは、ほとんどの場合、テクノロジーを選択する際の主要な決定ブロックです。
APIの開発やテストなどについて心配する必要はなく、プロジェクトの独自の実装に集中できます。
それが役に立てば幸い！
SignalRは、JavaScript、.NET、WinForms、WPFの複数のクライアントで簡単に使用でき、C++クライアントでも使用できます。セルフホストの.NETシグナルサーバー（OWIN）を使用することは、複数のクライアントにプッシュ/受信/ブロードキャストするスタンドアロンサーバーを実現するための素晴らしい方法です。より簡単なのは、パブリッシュサブスクライブ方式を使用したZeroMQだけです。
これまで誰も提起していない1つのポイント：
- SignalR 1.0.1では、サーバーとクライアントに.NET 4が必要です。対象とするクライアントとサーバーのバージョンによっては、考慮する必要がある重要な要素になる場合があります。
新しいデータを定期的に更新するだけの場合は、二重のWCFやシグナルを使用するのではなく、クライアント側からWCFとポーリングメカニズムを使用する方がよい場合があります。