Nachrichten für mehr als 10.000 Rechner im Netzwerk - Welche Technik verwenden?

Moin zusammen,

in unserer Firma habe ich einen kleinen Client, der versteckt im Hintergrund läuft und jede Minute in eine Datenbank schaut, ob eine relevante Nachricht vorhanden ist und danach seine Verbindung wieder schließt. Wenn ja, dann wird sie angezeigt.
Es ist ein Taskleisten (ganz rechts) -Anwendung.
Derzeit sind es um die 2000 Rechner, die ein Datenbankverbindung aufbauen.

Ich frage mich jetzt nur, ob das der beste Weg ist.

Meine möglichen Lösungen (ich habe nur keine Ahnung in Bezug auf die Performance bei mehr als 10.000 Rechnern).

1. Jeder Rechner schaut alle Minute in eine DB
2. Sockets Server / Client Anwendung ähnlich wie bei einem Chat (habe davon nur überhaupt keine Ahnung)
3. ???

Ich würde es toll finden, wenn Ihr mir mit eurem Wissen weiterhelfen würdet, welcher Weg der beste wäre für solch eine Anzahl an Rechnern - mehr als 10.000.

Vielen Dank im Voraus.
Sven

Hallo,

führt denn jeder Client für sich eine individuelle Abfrage durch? Evtl. wäre es besser einen Applikationsserver aufzusetzen, mit dem sich die Clients verbinden - und dieser verbindet sich dann nur mit der Datenbank. Denn so wie du es bisher hast, muß ja in jedem Client die Zugangsdaten zur DB abgespeichert sein.
Der Vorteil vom Applikationsserver wäre, daß dieser die Datenbankverbindungen besser steuern kann (d.h. evtl. auch Anfragen/Ergebnisse cachen kann).
Für die Datenübertragung zwischen Client und Server würde sich z.B. Windows Communication Foundation (WCF) anbieten.

Ohne den Code zu kennen, würde ich sagen gibt es hier noch nicht die optimale Lösung.

Ich würde die Clients nicht direkt auf die DB zugreifen lassen.
Ich würde dies eher mit einem Webservice usmetzen.
Wenn du weißt, dass nur alle X Minuten neue Nachrichte reinkommen, könntest du in deinem Webservice die Nachrichten ggf. cachen lassen.
Hier musst du dann nur einen Abgleich zwischen dem Cache und der DB Programmieren.
Aber ohne Details, wie die Clients aktuell auf die DB zugreifen oder ob du dies auch einfach umstellen kannst, kann ich dir keine optimale Lösung vorschlagen.

Aber direkt x Tausend Clients auf die DB zu schicken, halte ich nicht für den richtigen Ansatz.
Gerade bei einem Umzug der DB müsstest ihr alle Clients neukonfigurieren.
Bei 1.000 Clients wäre das schon ein riesen Aufwand.

Würde mich über Details, soweit möglich, freuen um dir Tipps zu geben. 😃

@Th69
Warst leider ein paar Sekunden schneller 😄

T-Virus

Vielen Dank für die Antworten.

Derzeit wird eine zentrale Anwendung aus dem Netlogon Verzeichnis des Domänenkontrollers beim Anmelden eines Benutzers an der Domäne gestartet.
In dieser Anwendung wird der Client für die Nachricht ggf. aktualisiert und danach versteckt im Hintergrund gestartet.

Die Datenbankverbindung ist im Client fest hinterlegt. Sollte sich was ändern, kann ich über die zentrale Anwendung, den Client aktualisiert.

Auf jedem Rechner läuft der Client versteckt im Hintergrund. Jede Minute wird eine DB Verbindung geöffnet und geschaut, ob eine Nachricht vorhanden ist.
Danach wird die DB Verbindung geschlossen und es wird wieder eine Minute gewartet, bis zum nächsten Check.

Das ist die aktuelle Lösung, Ich bin aber für alle Vorschläge offen, da ich glaube, dass die DB Lösung ein Problem werden kann.

Aktuell habe ich den Client abgeschaltet, da ich mir eine optimale Lösung für den Versand einer Nachricht an die ca. 10.000 Computer überlegen muss. Push oder Pull, dass ist auch die Frage, wobei ich Pull besser finde. Bauchgefühl.

Die Nachricht kommt von unserem HelpDesk, der z.B. mitteilen möchte, dass die Drucker gerade nicht funktionieren.

Das Ziel ist es, ein kleines Nachrichtenfenster auf dem Rechner zu starten, welches eine Nachrichten vom HelpDesk anzeigt, um Massenanrufen zu vermeiden, wenn es Problem gibt, wie gesagt, z.B. mit den Druckern oder SAP.

Ich habe gerade erst mit C# angefangen. Seit ca. 14 Jahren programmiere ich in Delphi. Daher bitte nicht zu komplizierte Lösungen 😃

Vielen Dank im Voraus.
Sven

@piro299
Leider musst du hier mit komplizierten Lösungen rechnen, da dies auch ein kompliziertes Problem ist.
Du wirst dich hier in C# einarbeiten müssen und die entsprechenden Techniken lernen müssen.
Wir geben hier nur Lösungsansätze und erarbeiten dir keine fertigen Lösungen.
Dies liegt bei dir.

Entsprechend solltest du dir WCF anschauen und prüfen ob sich dies so für euch umsetzen lässt.
Dann braucht ihr eben einen kleinen Zentralen Server der dann die DB Verbindung aufbaut, die Nachrichten abruft und dann entsprechend Cacht.

Die Umsetzung sollte mit WCF und einer entsprechenden Anpassung im Client eigentlich kein riesen Aufwand sein.

T-Virus

Danke.

Ich habe es mir gedacht 😃 Kein Problem. Arbeite mich da gerne ein. Ist ja ein spannendes Thema.

Ich gehe mal davon aus, das ein kleiner zentraler Server ist ein Anwendung ist. Richtig?

Holen Sich die Clients dann die Nachrichten oder werden Sie gepusht? Und wir dann eine Client / Server Anwendung mit Sockets verwendet?
Haben Socket Verbindungen ein Limit, wieviel Verbindung sie aufnehmen können?

Sorry für die Neugier aber das würde ich gerne vorher wissen.

Dann werde ich mich mal mit WCF auseinandersetzen.

Könnt Ihr mir Bücher oder sonstige Tutorials empfehlen, um das Thema schneller zu lernen?

Gruß
Sven

Hi,

bei Enterprise Anwendungen wirst du nie deine Applikation direkt auf die DB zugreifen lassen.

Dafür verwendet man einen Service der zwischen Client Applikation und DB vermittelt.

In deinem Fall hätte ich, wie bereits Th69 vorgeschlagen hat, auf einen bidirectional wcf zurückgegriffen.

Damit kannst du das Pooling vermeiden. Der Service teilt den Clients mit (push), dass beispielsweise neue Daten vorhanden sind und feuert dafür ein Event.

Wie sich das mit 100000 Clients verhält kann ich dir aber nicht sagen. Vlt. kannst du was mit Load Balancing WCF services anfangen.

Einen Schnelleinstieg gibt es unter Exemplarische Vorgehensweise: Erstellen von und Zugreifen auf WCF-Dienste
Detailliertere Infos gibt es unter WCF Tutorial.net ("Getting Started" ff.)

Bei 10.000 braucht man i.d.R. für ein reine Notification keinen Load Balancer.
Das muss dann schon ne sehr große Nachricht sein 😃

WCF halte ich hier etwas zu überdimensioniert.
Würde in diesem Fall hier auch SignalR empfehlen; einfach weil es viel leichter und schneller umzusetzen ist als WCF und diese Anforderung hier genauso erfüllt.

Kleiner Hinweis, egal ob WCF oder SignalR: alle Application Pool Instanzen haben ein Limit von 5000 Verbindungen pro CPU, der aber über die Config verändert werden kann.

Könnte man auch Sockets verwenden?

Einen Server, der die Verbindung zu DB hat und bei Fragen vom Client, eine Antwort gibt.

Die Clients fragen dann alle Minute den Server, ob es was neues gibt.

Wäre das auch eine Idee?

Nein.
Polling ist genau das, was unnötig Last verursacht.

Ok,

dann muss mein Server die Nachricht an die Clients senden.

Dann muss ich aber wissen, wer alles online ist. Mmmh.

Sorry, habe es noch nicht so richtig.

Habe mir mal WCF angesehen. Da muss ich mal ein Beispiel programmieren.

Also aus der Erfahrung macht es am meisten Sinn, wenn ich Push verwende.

Soll heißen, der Server hat eine Nachricht für die Clients und sendet diese dann.

Richtig?

Clients verbinden sich mit dem Server, und der Server hält die Infos, welche Clients verbunden sind. Das sind in der Regel Socket Verbindungen, die einfach offen sind aber keine Last verursachen (typischerweise WebSockets).
Ein Server kann hier hundertausende offene Sockets haben.

Gibt es eine neue Nachricht, dann iteriert der Server über alle verbundenen Clients und schickt die Nachricht raus.
Oder wenn die Nachricht spezifisch ist, dann eben nur an einzelne Clients.
So funktioniert jedes Pushsystem im Groben.

Am einfachsten ist eben SignalR, weil es genau für diesen Anwendungsfall gedacht ist.
Vermutlich wirst Du 2-3h für erste Beispiele brauchen, damit Du das System verstehst, aber der effektive Code sind keine 50 Zeilen.

WCF ist hier Kanonen auf Spatzen.
Funktioniert natürlich auch, aber SignalR ist hier viel einfacher.

@Abt. Danke für die Erklärung. Jetzt habe auch ich es verstanden.

Dann werde ich mich mal ans Lernen machen. Vorallem SignalR.

Hallo piro299,

nur als Zusatz zu dem von Abt gesagtem: SignalR hat einen Fallbackmechanismus der erstmal WebSockets versucht aber falls das nicht möglich ist auf SSE, ForeverFrame und dann LongPolling zurückfällt. (Da hast du dein Polling wieder 😉). Achtung LongPolling ist nicht gleich Polling.

Am Ende erledigt SignalR diese ganzen Sachen für dich, daher ist es sicher die richtige Wahl.

Gruss

Coffeebean

Vielen vielen Dank an alle.

SignalR wird meine Lösung.

Hier habe ich einen guten Link gefunden.
http://www.codeproject.com/Articles/804770/Implementing-SignalR-in-Desktop-Applications

Danke nochmal und noch ein schönes Wochenende.
Sven