約1,000人の従業員PCにインストールされるWindowsフォームアプリケーションを開発しています。ユーザーは、アプリケーションの複数のインスタンスを同時に実行できます。クライアントはすべて単一のイントラネット上にあります。
アプリケーションを変更すると、データベースレコードが変更される可能性があります。この変更は、UIが更新されるように、他のクライアントに伝達する必要があります。
私たちのチームは、2つの異なるアプローチについて話しました。
1.マルチキャストパケット
ソースクライアントはレコードを変更してから、何かが変更されたペイロードを含むマルチキャストパケットを送信します。他のクライアントはこれを受け取り、指定されたデータをフェッチします。パケットが受信されず、データのアクティブな取得にフォールバックする場合を考慮する必要があります。
この時点での私の質問は、クライアントがパケットを受信しなかったことをどのようにして知るのかということです。（何がわからないのかわからない）これにより、データベース内のタイムスタンプを含むある種のイベントログが表示され、UIコントロールはそれらが最後に更新された時刻を追跡します。それらは焦点を合わせ、タイムスタンプをチェックし、必要に応じて更新します。
他の誰かは、UI要素がフォーカスされるたびにリロードするだけだと言いました（Outlookのモードを考えて、CABを使用してスタックワークスペースの前面にコントロールを表示します）。そして、マルチキャストは、現在のコンテキストが変更されたことをクライアントに更新することです。見逃した場合は、モードを変更して戻ってくるまで、古いデータを処理します。
2.WCFとコールバック
クライアントは、tcpバインディングを介したコールバックのWCFコントラクトに登録します。これに関する主な技術的懸念は、サーバーが多くの開いているソケットを維持していることです。従来の意味で開いていないことを確認しました。最大90秒間スリープ状態になり、その時点で再確立されます。また、Windows 2003 Serverマシンが処理できるオープン接続の最大数と、レジストリでそれを変更する方法についても説明しました。
サーバーへの1,000のオープンソケット接続がある場合、これは崩壊しますか？
誰かがこれと同じ状況に直面し、WCFアプローチを試したり評価したりした場合は、それについて聞いてみたいと思います。