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

[Piro]

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.

In einem CSharp Forum wurde mir SignalR empfohlen? Link :http://www.mycsharp.de/wbb2/thread.p...80#post3784780
Wollte es erst in C# machen aber hier bin ich noch Anfänger.

Vielen Dank im Voraus.
Sven

[TheMiller]

Es kommt auf Plattform an, würde ich sagen.

Generell würde ich diese Aufgabe von einem MessageBroker / MessageQuere erledigen lassen. Nutzt ihr alle ausschließlich Windows, dann der Einfachheit halber Microsoft Message Queue Server. Der ist beim Windows-Server dabei, muss nur aktiviert werden.

Nutzt ihr verschiedene Betriebssysteme oder sogar Mobile-Clients, dann über eine Webseite mit Websockets. Dort läuft dann ein Websocket-Router oder Server zB Crossbar.io oder Node.js etc.pp. Mit Crossbar kannst du den Socket in jeder Sprache schreiben (naja, fast jeder) und dennoch Clients aller Art bedienen. Die Architektur dahinter ist allerdings sehr umfangreich - ich habe das gerade selbst umgesetzt.

Also, Windows = MSMQ
PHP = RatchetPHP, Thruway, Crossbar.io
JS = Node.js

AUf der Serverseite fragt eine Verbindung nach neuen Daten, alle Clients registrieren sich in der Queue und werden bei neuen Daten benachrichtigt, bzw. die Daten werden gleich mitgeschickt.

Ich hoffe, ich konnte auf die Schnelle ein wenig helfen.

[Valle]

Klar ist schonmal, dass jede Minute die Datnebank zu pollen, definitiv nicht die beste Möglichkeit ist. :stupid:

Technisch am besten dafür geeignet wäre im Prinzip eine Multicast Nachricht. Jeder der teilnehmenden Rechner schreibt sich in die entsprechende Multicast Gruppe ein und der Server sendet eine Multicast Nachricht an diese Gruppe, sobald ein bestimmtes Event eingetreten ist. Die richtige Hardware vorausgesetzt bekommt so jeder der 10.000 PCs gleichzeitig seine Nachricht und die benötigte Bandbreite könnte geringer gar nicht sein.

Leider ist das nicht immer eine mögliche Option. Billige Switches spielen da nicht mit, der Konfigurationsaufwand ist nicht zu unterschätzen und über das Internet funktioniert diese Technik nicht. :-/

Auf jeden Fall würde ich zur Lastreduzierung vom Polling wegkommen und stattdessen ein zentrales Prinzip einführen. Die erwähnten WebSockets sind in der Tat eine Option, allerdings solltest du die Technologie verwenden, mit der du am besten vertraut bist. Wenn deine Anwendung mit Web nichts zutun hat und du auch mit node.js und Konsorten nicht vertraut bist, sehe ich wenig Sinn dahinter, den gesamte Overhead dieser Technologie mitzunehmen.

Stattdessen würde ich dann eher herkömmlichen TCP-Verbindung zurückgreifen. Du musst bei der Implementierung darauf achten, dass 10.000 Verbindungen ziemlich viele sind. Das bedeutet für dich, dass du bei der Implementierung schauen müsstest, dass du nicht 10k Threads oder gar 10k Prozesse startest. Stattdessen würde wenige Threads zur Abarbeitung aller Verbindungen ja genügen.

[himitsu]

Wenn er selber was mit TCP macht, warum dann nicht besser ein Netz, anstatt einem Stern?

Entweder mehrere Server (PCs+Programm) oder die Clients bauen untereinander Verbindungen auf.
Diese 10.000 Rechner werden ja nicht alle im selben (lokalen) Netz hängen, also da eher über die Welt verstreute Server und mmer mit dem "nächsten" verbinden, oder in den verschiedenen lokalen Netzen sprechen sich die Clients ab, wobei sich dann einer/mehrere auch als "Server" bereit stellen, über den die Anderen mit dem Server rden, bzw. von denen sie die Multicastnachrichten bekommen.

Quasi wie bei vielen FileSharingDiensten ala Torrent.

[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:

Zitat von TERWI (Beitrag 1332326)

Oder jemand noch bessere Ideen ?

Sagen wir mal so...

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

[mjustin]

Zitat:

Zitat von Piro (Beitrag 1332263)

3. ???

MSMQ wurde bereits erwähnt. Es gibt als Alternative auch viele Free Open Source Message Broker. Zwei, die sehr verbreitet im produktiven Einsatz sind, können über diverse Client-Bibliotheken auch von Delphi/Free Pascal aus verwendet werden:

* Apache ActiveMQ (Java-basiert, Clients in C/C++, C#, PHP, Pascal, Perl, Python, ...) unter http://activemq.apache.org/
* RabbitMQ (Erlang-basiert, Clients in Java, C#, Ruby, Python, PHP, JavaScript, Pascal, ...) - http://www.rabbitmq.com/

[TERWI]

@ Mavarik
... wohl wahr - wie immer !

@ mjustin
Free Open Source Message Broker ? Indianer und andere Hasen ???
Was haben die mit der Entwicklung eines sauberen und schlanken Programmes zu tun ?

Eher NIX !?

Damit wird nur massiv auf/eingesetzt und anderen das Denken überlassen, die/wo/da/so dann doch mit nennenswerter/überdimensionierter Performance NUR mit MEGA-EURO für Hardware, welche die schlecht gemachte Software wieder rausreissen muss ....

Aktuell finde ich es sehr erstaunlich, hier noch mit 9000/700 am start zu sein. Nicht der Brüller - manche anderen würden sich freuen.

[mjustin]

Zitat:

Zitat von TERWI (Beitrag 1332337)

@ mjustin
Free Open Source Message Broker ? Indianer und andere Hasen ???
Was haben die mit der Entwicklung eines sauberen und schlanken Programmes zu tun ?

Eher NIX !?

Alle Message Broker (auch MSMQ) haben den Vorteil, dass sie eine bestimmte Aufgabe übernehmen, die dann nicht mehr in jedem einzelnen Programm eingebaut sein muss. Das führt auch zu kleineren, schlankeren Programmen, weil nur noch wenige Kilobyte für das Protokoll und den Netzwerkstack benötigt werden. Für Routing, und bei Bedarf auch Persistenz und vieles mehr, ist der Broker zuständig (der auch mit guter Leistung in einer kleinen virtuellen Maschine betrieben werden kann).

Zitat:

Zitat von TERWI (Beitrag 1332337)

Damit wird nur massiv auf/eingesetzt und anderen das Denken überlassen

Wer die Lust und Zeit dafür hat, darf sich natürlich alle Server selbst bauen - Datenbanken, Mailserver, Webserver, ... (Ohne Pioniergeist und Investitionen kein Fortschritt). In der Praxis gibt es aber immer auch Rahmenbedingungen und Interessenslagen, die die Auswahl einer bestehenden Lösungen begünstigen machen, wenn damit ein gesetztes Ziel erreicht werden kann (auch wenn es etwas mehr kostet als eine selbst "gebraute" Lösung). Türklinken müssen nicht vergoldet sein.

[mjustin]

Zitat:

Zitat von Piro (Beitrag 1332263)

Derzeit sind es um die 2000 Rechner, die ein Datenbankverbindung aufbauen.

Noch eine Alternative: falls die Datenbank Events unterstützt (InterBase, Firebird z.B.), kann man diese im Client 'abonnieren'.

Beispiele, Vor- und Nachteile habe ich in einem Blog Artikel (Englisch) beschrieben unter https://mikejustin.wordpress.com/201...ed-middleware/

Eventuell auch interessant ist: Why is a database rarely the best tool for a queue based problem

[Piro]

Moin,

Vielen vielen Dank für die zahlreichen Antworten. Sorry fürs späte Melden. Ich saniere gerade unser Haus.

Meine Idee:
In unserem Firmennetzwerk, welches weltweit ist, soll eine kleine Anwendung auf jedem Windows Computer bei Logon via Group Policy gestartet werden.
Anhand des Active Directory SiteName aus der Registry melden sich die Computer an dem Nachrichten Server an.
Mit einem Management Programm kann ich dann eine Nachricht in die Datenbank schreiben mit dem Zusatz, welche Standorte auf Basis des SiteName eine Nachricht bekommen sollen.
Eine kleines Programm kontrolliert dann alle Minute, ob eine neue Nachricht vorhanden ist und sendet diese dann an die relevanten Computer.

Dadurch muss ich folgende Programme programmieren:
1. Management PGM ( ist schon fertig)
2. Nachrichtenserver, der alle Client Verbindungen annimmt und die DB auf neue Nachrichten überprüft
3. Client PGM, welches auf jedem Computer gestartet wird, welches sich am Server anmeldet

Ich würde gerne alles mit Delphi umsetzen, wenn es machbar ist. Außer es wäre mit anderen Tools sinnvoller.

Danke im Voraus.
Sven

[madas]

Zitat:

Zitat von Piro (Beitrag 1332345)

Ich würde gerne alles mit Delphi umsetzen, wenn es machbar ist. Außer es wäre mit anderen Tools sinnvoller.

Vielleicht kommt Dir diese Antwort hier bekannt vor:

Zitat:

Vielen vielen Dank an alle.

SignalR wird meine Lösung.

http://www.mycsharp.de/wbb2/thread.php?threadid=116512

Warum nun doch wieder Delphi, wenn SignalR wirklich eine sehr gute Lösung darstellen würde?

[Piro]

Ja das mit SignalR ist doch etwas zeitaufwendiger als gedacht. Da muss ich mich mit der Materie von ganz vorne auseinandersetzen.
C# und GUI und so weiter, sind für mich totales Neuland. Leider habe ich die Zeit nicht und Delphi ist für mich vertrauter.

Wenn ich die Zeit hätte, wäre es vielleicht anders.

Deshalb die Idee, ob Delphi irgendwelche Techniken hat, w.z.B. SignalR, um mein Vorhaben mit Delphi Mitteln umzusetzen.

Wie gesagt, habe ich schon eine fertige Management Anwendung in der ich alle Rechner habe. Mit dieser kann ich die zu verschickende Nachricht in die DB speichern.
Jetzt fehlt mir nur noch der Server und die Client Anwendung mit mein Vorhaben mit den richten Mitteln, umzusetzen.

Gruß,
Sven

[mjustin]

Zitat:

Zitat von Piro (Beitrag 1332403)

Deshalb die Idee, ob Delphi irgendwelche Techniken hat, w.z.B. SignalR, um mein Vorhaben mit Delphi Mitteln umzusetzen.

Eine kommerzielle WebSocket Client und Server Implementierung gibt es unter http://websockets.esegece.com/

Code:

    Fully functional multithreaded WebSocket server according to RFC 6455.
    Supports Firemonkey (Windows, MacOS, iOS and Android).
    Supports Lazarus / FreePascal.
    Supports CBuilder.
    Supports C# .NET through sgcWebSockets.dll
    Supports Chrome, Firefox, Safari, Opera and Internet Explorer (including iPhone, iPad and iPod)
    Binary and Full Unicode Messages Support
    Message compression using PerMessage_Deflate extension.
    Flash FallBack for Web Browsers without native WebSockets (like Internet Explorer 6-9).
    Multiple Threads Support
    Server component providing WebSocket and HTTP connections through the same port.
    Client WebSocket supports connections through Socket.IO Servers.
    Client WebSocket supports connections through HTTP Proxy Servers.
    WatchDog and HeartBeat built-in support.
    Events Available: OnConnect, OnDisconnect, OnMessage, OnError
    Built-in sub-protocols: JSON-RPC 2.0(Transactional Messages, PubSub, RPC, Queues, QoS and more), Datasets, Binary Files, WebRTC and WAMP.
    Built-in Javascript libraries to support browser clients.
    Easy to setup
    Javascript Events for a full control
    Async Events using Ajax
    SSL/TLS support on Server and Client components

Ob das über 10000 Connections schafft sollte der Author sicher beantworten können. Ich würde aber zur Sicherheit immer auch eigene Lastsimulationen durchführen.

Indy-basierte Lösungen sind allerdings nicht für so hohe Verbindungszahlen geeignet wenn die Connections alle gleichzeitig geöffnet sein müssen. (nachzulesen z.B. unter http://codeverge.com/embarcadero.del...read-c/1072348).

Wenn es 20000 Clients sein sollen und der Server in Delphi implementiert werden muss, könnte man

* mehrere Server laufen lassen (um die Last zu verteilen)
* die Verbindung nur kurz geöffnet lassen und serverseitig die wartenden Informationen in einem Cache halten, damit der Client sehr schnell wieder die Verbindung trennen kann *)
* UDP verwenden um Clients über neue Nachrichten zu informieren

*) aber das Betriebssystem wird dann den Socket immer noch für längere Zeit offen halten. Wenn sich viele Clients immer wieder verbinden und trennen, kann das Betriebssystem dann nach einiger Zeit keine neuen Sockets mehr öffnen (das ist einer der Gründe warum z.B. HTTP 1.1 die Verbindung geöffnet hält - 'HTTP/1.1 makes persistent connections the default.' - http://www8.org/w8-papers/5c-protocols/key/key.html )

[Piro]

Moin,
habe mich jetzt doch mit SignalR und C# auseinander gesetzt. Ist echt cool.

Werde SignalR verwenden.

Vielen Dank für die gute Unterstützung und die Anregungen.

Mit freundlichen Grüßen
Sven