2009-05-25 6 views
6

Ich habe eine Client-Server-Anwendung - wobei der Server im Wesentlichen eine ASP.NET-Webanwendung und die verteilten Clients sind Desktop-Anwendungen.Der Client (Desktop-App) zieht Daten ... aber ich möchte den Server (Web-App) Push-Daten

Die Clients müssen einige Daten vom Server erhalten - wenn neue Daten für den Client vorhanden sind. Im Augenblick ist dies so: Der Client fragt alle x Minuten (z. B. 2 Minuten) einen Web-Service ab und überprüft, ob neue Daten für den Client vorhanden sind.

Im Idealfall sollte es so funktionieren, dass die Desktop-App Updates erhalten sollte, sobald sie verfügbar sind und nicht vom Server abgerufen werden müssen. stattdessen sollte der Server in der Lage sein, an den Client zu senden.

Wie gehe ich vor? Angesichts der Architektur der Lösung muss eine Webanwendung Daten an Desktop-Anwendungen (Clients) im selben Netzwerk (einem LAN) übertragen.

Antwort

7

Was Sie beschreiben, ist "Server Push", die heutzutage oft "COMET" genannt wird. Die Verwendung dieser Schlüsselwörter in einer Websuche sollte viele nützliche Informationen enthalten.

Die gängigste Technik hierfür ist ein "hängenden GET". Der Client sendet eine GET-Anforderung an eine bestimmte URL, und der Server akzeptiert die Verbindung, verzögert jedoch das Senden einer Antwort, bis Daten gesendet werden können. Wenn der Client die Antwort erhält, sendet er einen weiteren GET, so dass er für eine weitere Nachricht bereit ist.

+1

Ich wollte nur eine Notiz, dass Sie den IHttpAsyncHandler (http://msdn.microsoft.com/en-us/magazine/cc164128.aspx) und System.Threading.Monitor verwenden können, um eine (Art von) ereignisgesteuert zu erstellen "Server Push" in .NET 2.0 Wenn jemand eine vollwertige Dienstprogramm-Klasse dafür kennt, posten Sie bitte einige Links – Radu094

+0

Für jeden Client muss der Server eine Socket-Verbindung am Leben erhalten. So wird es nicht funktionieren, wenn die Nr. von Kunden können nicht im Voraus vorhergesagt werden. –

0

Wenn Sie einen Socket offen lassen können, kann der Client eine Verbindung zum Server herstellen, und der Server kann Daten einfach durch den Socket schieben, wenn dies angemessen ist. Es gibt keinen Grund, warum die Seite, die die Verbindung initiiert, immer diejenige sein muss, die die Datenübertragung initiiert.

+0

Diese App ist für allgemeine Intranets in Branchen. Unter Verwendung von Socket-Verbindungen - d. H. Bei Verwendung eines Sockets würde ein Port für den Zugriff geöffnet werden müssen - Neukonfiguration der Firewall usw. usw. Ist dies eine vernünftige Installationsvoraussetzung oder werden sich Industriekunden im Allgemeinen diesem entgegenstellen? – Sameet

+0

Eine HTTP-Verbindung ist ein Socket. Was die Antwort (richtig) empfiehlt, ist, dass der Client ein GET sendet, aber der Server eine Antwort zurücksendet, bis Daten bereit zum Senden sind. –

+0

Ja, aber HTTP-Verbindung ist auf Port 80, der nicht durch Firewalls blockiert wird? Was Sie beschrieben haben, klingt perfekt - Server verzögert die Antwort, bis Daten vorliegen - wie geht das? – Sameet

2

Sie können WCF-Rückrufe verwenden - dies ist ein Webdienst, bei dem Sie Benachrichtigungen von einem Client abonnieren können und der Server Nachrichten an abonnierte Clients sendet. Ich habe eine beginners guide auf meinem Blog.

+0

WCF? Also mehr als nur .NET 2.0? Leider ist .NET 2.0 eine Einschränkung, unter der ich arbeiten muss? Werden WCF Callbacks in diesem Fall helfen? – Sameet

+0

Nein, Angst nicht, es ist WCF nur fürchte ich. – blowdart

1

Sie könnten Interesse an der SO question haben. Was Sie beschreiben, klingt wie eine Comet-Anwendung - Server-Push zu einem Client.

1

Auschecken WebSync; Es ist eine Comet-Lösung für ASP.NET/IIS, aber es gibt auch einen vollständigen .NET-Client, der die Integration mit Thick-Clients, Windows-Diensten usw. ermöglicht. Es klingt also so, als sollte es ziemlich gut zur Rechnung passen.

Verwandte Themen