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

[jobo]

Als Ergänzung zur Problematik:
Wenn eine schlanke Massenbenachrichtigung per Push realisiert ist, musst Du auch mit der Reaktion klarkommen.
Wenn vormals hunderte oder 2-tausende Rechner mit dem minütlichen Pollen wahrscheinlich eine rauschartige, hohe Grundlast auf dem Server produziert haben, könnte es nun mit pünktlichem Push an 10000 Systeme und anschließender DB Anfrage zu einer schlagartigen Überlast führen. Dabei kommt es auch darauf an, wie zielgenau bzw. ereignisspezifisch die Nachrichten verschickt werden, also an wieviele Clients /Gruppen.
"An alle: Es gibt neue Daten" ist weniger hilfreich als "An Etage 2, Nordtrakt: Neuer Drucker verfügbar"

[TheMiller]

Deswegen würde ich eine MessageQueue empfehlen, bei der sich die Clients registrieren und bei einem Event gleich die Nachrichten übermittelt bekommen. So sind die Daten gleich verfügbar. Oder man sendet in die Nachricht einen timestamp mit, wann sich der Client X mit dem Server verbinden und die Daten laden soll. (Die ersten 500 sofort, die nächsten 500 in sofort+x Sekunden, etc.pp).

Als MessageQueue kann ja der MS-Server (MSMQ) benutzt werden. Schnelle, saubere, skalierbare Lösung.

[TERWI]

Quizfrage wäre noch vielleicht:
Sitzen diese 2000 (-1000) alle im gleichen Adress-Bereich ?

Polling von jedem Rechner wäre wohl die eher dümmste Idee ...
(... was ein unsinniger Traffic am Server ....)

Jeweils ein Multicast bei neuen Info's an alle mit speziellen Daten WEN WAS betrifft.
Die "Lauscher" sollten logo schon auf entsprechende Daten hören / diese auswerten.

Falls es mehrere Empfänger gleichzeitig betrifft, könnten die dann ja explizit beim Server noch mal nachfragen (hier dann im Polling), ob z.B. die Info schon abgearbeitet wurde oder noch relevant ist.

Nach dem Motto: Ich bin frei, gib her, brauch sich keiner weiter kümmern.

Typische CallCenter-Anwendung ?!

[Mavarik]

Pollen ist sicherlich die schlechteste Variante...

UDP Broadcast sicherlich die schlankeste...

Dann eher eine Restservice als das jeder Client seine eigene Datenbankverbindung aufbaut...

Mavarik

[TERWI]

Nachtrag:

... logo sollten nicht alle Server beim Multicast des Clienten ah hoc zurücksenden.
Auch das gäbe mächtigen Stress bei Absender, alle Antworten ala "Bin da, wer noch ?" auszuwerten / zu verwalten.

Hier sollte der Server/Lauscher mittels kleiner Eigenintelligenz zunächst mal checken, ob er überhaupt "ansprechbar" ist (nicht besetzt, MA in Pause, unterwegs, im Gespräch oder anderweitig "besetzt".

Mit Berücksichtigung, das auch nicht alle angesprochenen Rechner aktiv sind, reduziert das den Traffic sicher ungemein !

Ergänzed könnte man das Pferd logo auch anderes herum aufzäumen:
Jeder Server meldet sich nach Aufgabenübertragung anschließend wieder beim CLienten/Master "frei" und reiht sich in die Liste der nächsten, zu beauftragenden "Geräte" wieder unten ein.

Der Master könnte so gezielt den nächsten Server direkt von der Listen ab TOP ansprechen und Aufgaben verteilen.
Das gäbe bei "energiebedarften Geräten" auch ein wenig Luft für "Cool-Down" by the way ..
"Handshaking" sozusagen - vor und nach der pause oder permanent bei Voll-Last.

Erst wenn die Liste leer wäre - to much to do - käme ein evtl. Multicast-Ping als Anfrage (... mach hinne, hier liegt Arbeit ohne Ende ...) in Frage.

Niemand/nix frei ? Dann muss halt ne Warteliste aufgebaut werden ....
"... im Moment sind alle MA im Gespräch ..."
Bis (hoffentlich) wieder Ruhe einkehrt und wieder 'gezieltes' PING an den nächsten funktioniert.

Methoden ala BruteForce machen mehr kaputt als dass sie helfen.
Eile mit Weile !

Oder jemand noch bessere Ideen ?

[Mavarik]

Zitat von TERWI:

Oder jemand noch bessere Ideen ?

Sagen wir mal so...

Für die richtig guten Ideen hat der TE uns viel zu wenige Infos gegeben...