私はクライアント サーバー アプリケーションを使用しています。サーバーは本質的に ASP .NET Web アプリケーションであり、分散クライアントはデスクトップ アプリケーションです。
クライアントに新しいデータがある場合、クライアントはサーバーからデータを受信する必要があります。現在、これが行われる方法は次のとおりです。クライアントは x 分 (たとえば 2 分) ごとに Web サービスにクエリを実行し続け、クライアントの新しいデータがあるかどうかを確認し続けます。
理想的には、それが機能する方法は、デスクトップ アプリが利用可能になったときに更新を受信することであり、サーバーから取得する必要はありません。代わりに、サーバーはクライアントにプッシュできる必要があります。
ソリューションのアーキテクチャを考えると、Web アプリケーションは同じネットワーク (LAN) 内のデスクトップ アプリケーション (クライアント) にデータをプッシュする必要があります。
あなたが説明しているのは「サーバープッシュ」であり、最近では「COMET」と呼ばれることがよくあります。Web検索でこれらのキーワードを使用すると、多くの有用な情報が得られるはずです。
このための最も一般的な手法は、「ハンギングGET」と呼ばれます。クライアントは特定のURLにGET要求を送信し、サーバーは接続を受け入れますが、送信するデータが得られるまで応答の送信を遅らせます。クライアントが応答を受信すると、別のGETを送信するため、別のメッセージの準備が整います。
WCF コールバックを使用できます。これは、クライアントからの通知をサブスクライブできる Web サービスであり、サーバーはサブスクライブしたクライアントにメッセージを送信します。私のブログに初心者ガイドがあります。
あなたはSOの質問に興味があるかもしれません。あなたが説明していることは、Cometアプリケーションのように聞こえます-サーバーがクライアントにプッシュします。
WebSyncをチェックしてください。これは ASP.NET/IIS 向けの Comet ソリューションですが、シック クライアントや Windows サービスなどとの統合を可能にする完全な .NET クライアントも利用できます。
ソケットを開いたままにしておくことができれば、クライアントはサーバーに接続でき、サーバーは必要に応じてデータをソケットにプッシュできます。接続を開始する側が常にデータ転送を開始する側でなければならない理由はありません。