Client/Server Projekt: Daten filtern und verteilen???

[romber]

Guten Abend zusammen :cheers:

Habe da eine grobe Beschreibung eines neuen Projekts und brauche dringend Eure Experten-Tipps. Folgende Aufgabe:

Es gibt einen Server. Der Server bekommt über eine API (Webservice) die Daten geliefert, die dann gefiltert und an die Clients verteilt werden.

Dann gibt es eine Versicherungsagentur mit mehreren dutzend Mitarbeitern. Jeder Mitarbeiter bekommt auf seinem PC die Client-Applikation installiert. Über diese Client-Applikation kann der Mitarbeiter mehrere Filter erstellen. Alle Filter werden zentral auf dem Server gespeichert. Bei jedem gelieferten Datensatz prüft der Server, ob der Datensatz zu einem (oder mehreren) der gespeicherten Filter passt und leitet die Daten möglichst zeitnah an den/die Filterinhaber weiter.

Die Clients dürfen natürlich nicht direkt mit dem SQL Server kommunizieren, die ganze Client-Server-Kommunikation läuft über eine Zwischenebene und ist überhaupt kein Problem. Das einzige, worüber ich mir Sorgen mache ist die Filterung und anschießende Verteilung der Daten. Wie realisiere ich das am Besten? Bis jetzt sind mir nur zwei Optionen eingefallen:

1. Für jeden aktiven Client eine temporäre Tabelle erstellen und dort die für den Client bestimmte Daten ablegen
oder
2. In der Serversoftware für jede Client-Verbindung einen Datencontainer erstellen, der jedesmal nach der Datenübertragung umgehend wieder geleert wird

Sicher gibt es noch andere und bessere Varianten. Wie würdet Ihr das ganze machen? Wie ich bereits erwähnt habe, ist es sehr wichtig, dass die Daten möglichst schnell den Client erreichen.

Im Voraus vielen Dank!

[Medium]

Ich nehme an, jeder Client (bzw. Benutzer) ist mit einem User identifiziert, der sich in einer User-Tabelle definiert findet. Somit wäre eine einzelne Tabelle doch ganz nett, in der sämtliche Datensätze landen, mit einem Fremdschlüssel auf die User-ID. Der Client bekommt dann beim Connect die zu ihm gehörenden Daten gesendet, und quittiert dem Server jdeden empfangenen Satz mit dem Echo der Satz-ID, der darauf hin den Satz aus der Tabelle entfernt. Alternativ belässt man ihn dort, und sendet immer alle Sätze beim User-Connect (und Neueingang von Sätzen), und löst die Löschung auf Userinitiative hin aus - ähnlich wie bei E-Mails in einem Clientprogramm, bei denen der Server die Mails bestehen lässt, bis der User die auch in seinem Client gelöscht hat.
Dabei böte sich noch eine kleine embedded DB im Client an, die bereits empfangene aber ungelöschte Sätze puffert, deren IDs beim Connect mit gesendet werden, so dass diese nicht erneut übertragen werden müssen. Ob das nötig ist, hängt dann von dem Verhältnis von Netzkapazität zu -last ab.

[Sir Rufo]

Ich unterstelle mal, dass es da eine Menge Datensätze gibt, die zu vielen Usern geliefert werden müssen.
Von daher würde sich ja eine Zwischentabelle lohnen, wo nur die UserID und die DatensatzID enthalten ist.

Der Rest analog wie Medium das vorgeschlagen hat.

EDIT

Wie schnell muss denn schnell sein? Realtime, 10ms, 10s, 1m, 10m?
Ab einer Minute ist Polling ausreichend, alles was darunter ist, müsste man mit einer aktiven Signalisierung vom Server zum Client realisieren.

[mjustin]

Sogenannte Message Broker wie Apache ActiveMQ bieten diese Features:

* eine Nachricht kann gezielt an bestimmte Clients gesendet werden (anstatt Polling)
* Nachrichten können aber auch über einen 'Kanal' - auch 'Topic' (Thema) genannt - an alle Clients zugestellt werden, die diesen Kanal abonniert haben. Wenn man im konkreten Anwendungsfall je Filter einen Kanal definiert und die Nachrichten vom Server in diesen Kanal schreibt, erhalten alle Client diese Nachricht
* Eine weitere Filterungsmöglichkeit sind 'Selektoren', dies sind serverseitige Filter die der Client vorab dem Server mitteilt damit er Nachrichten nur dann dem konkreten Client zusendet, wenn sie bestimmte Kriterien erfüllt
* Wildcards ermöglichen das Filtern mehrerer Topics innerhalb einer Hierarchie



Da es Clientbibliotheken für viele Programmiersprachen gibt, kann zum Beispiel schon der Webservice (er kann in C#, Java, PHP oder Delphi geschrieben sein) beim Annehmen der Daten die Nachricht für die Benutzer an den Broker senden.

Wie der Einsatz eines Message Brokers konkret an die Bedürfnisse der Anwendung angepasst werden kann, ist sehr detailliert im Buch "Enterprise Integration Patterns" von Gregor Hohpe beschrieben.


Zur Geschwindigkeit: Message Broker sind sehr schnell (tausende Nachrichten pro Sekunde sind eher die Untergrenze) und robust, sie werden daher sehr häufig im Finanzsektor (Börsenkurse) eingesetzt.

Mit Delphi erreiche ich auf einem langsamen Notebook zwischen 4.000 und 20.000 Nachrichtenroundtrips pro Sekunde, wobei Client und Server auf dem gleichen Rechner laufen. Roundtrip = vom Client zum Server und wieder zurück zum Client, 4000 Roundstrips sind also 4.000 ausgehend(Client->Server) und 4.000 eingehend(Server->Client) pro Sekunde. Mit Apache ActiveMQ sind es ca. 2.500, Apache Apollo ca. 4.000. Es spielt daher also eher die generelle Netzwerklatenz eine Rolle, d.h. wie gut die Verbindungen vom Client zum Server sind.

[romber]

Erstmal vielen Dank für die schnelle Reaktionen!

Wenn ich es richtig verstanden haben, schlagt Medium ein Modell vor, in dem sich die Clients regelmässig (z.B. ein Mal pro Sekunde) mit dem Server verbinden und die Daten abrufen. Genau dieses Verfahren möchte ich nur ungern einsetzen, da es mir nicht schnell genug zu sein schneint.

Zitat:

Zitat von Medium (Beitrag 1157863)

Der Client bekommt dann beim Connect die zu ihm gehörenden Daten gesendet, und quittiert dem Server jdeden empfangenen Satz mit dem Echo der Satz-ID, der darauf hin den Satz aus der Tabelle entfernt.

Mit sehr hoher wahrscheinlichkeit werden mehrere Client die gleiche Filter haben. Wenn der Datensatz aus der Tabelle entfernt wird, bekommen andere Clients die Daten nicht mehr.

Zitat:

Zitat von Medium (Beitrag 1157863)

Alternativ belässt man ihn dort, und sendet immer alle Sätze beim User-Connect (und Neueingang von Sätzen), und löst die Löschung auf Userinitiative hin aus

Es können bis zu 30 neue Datensätze pro Sekunde geliefert werden. Könnte schon ein Problem sein, wenn jedesmal alle Datensätze übertragen werden.

Zitat:

Zitat von Sir Rufo (Beitrag 1157864)

Wie schnell muss denn schnell sein? Realtime, 10ms, 10s, 1m, 10m?

Kritisch! So schnell wie es nur möglich ist. Am besten in Realtime natürlich. Daher schließe ich den Polling erstmal ganz aus.

Zitat:

Zitat von Sir Rufo (Beitrag 1157864)

Ab einer Minute ist Polling ausreichend, alles was darunter ist, müsste man mit einer aktiven Signalisierung vom Server zum Client realisieren.

Diese Aktive Signalisierung vom Server zum Client ist doch genau das, was mjustin mit Apache ActiveMQ vorgeschlagen hat, oder?

Zitat:

Zitat von mjustin (Beitrag 1157873)

Sogenannte Message Broker wie Apache ActiveMQ bieten diese Features

Sehr interessant. Habe mit "Habari Client Libraries" eine Delphi-Implementierung mit Demos gefunden und werde es mir jetzt genauer anschauen. Verstehe ehrlich gesagt noch nicht ganz, wie das Ganze funktioniert und vermute einen enormen aufwand dahinter. Ansonsten schneint von der Beschreibung her genau das Richtige für mich zu sein.

[Medium]

Zitat:

Zitat von romber (Beitrag 1157918)

Wenn ich es richtig verstanden haben, schlagt Medium ein Modell vor, in dem sich die Clients regelmässig (z.B. ein Mal pro Sekunde) mit dem Server verbinden und die Daten abrufen.

Eigentlich nicht :) Schon so, dass der Server pushed. Das einzige was der Client machen sollte ist sich anzumelden, woraufhin der Server ihn in seine Liste aktiver Zuhörer aufnimmt, und ihm nur nach frischem Connect ggf. alles Liefert, was er in der nicht verbundenen Zeit verpasst hat. Nur dafür müsste der Client beim Anmelden auch einmalig mit schicken, welche Sätze er schon alle kennt. (Alternativ ließe sich das sogar noch in der serverseitigen Tabelle mit einem netten Böölchen einfach abhaken, dann darf dier Client nur nie was löschen ohne Verbunden zu sein.) Ich würde schon versuchen Polling wann immer es geht zu vermeiden.

Es ist aber sicherlich auch keine schlechte Idee auf eine bestehende Lösung zu setzen, wenn diese zu deinen Anforderungen passt. So ganz ohne ist das nämlich nicht, vor allem je nach dem wie wasserdicht das werden soll (potenziell ne Menge Handshaking/Signaling).

[Sir Rufo]

[QUOTE=Medium;1157922]

Zitat:

Zitat von romber (Beitrag 1157918)

Nur dafür müsste der Client beim Anmelden auch einmalig mit schicken, welche Sätze er schon alle kennt.

Das sehe ich eigentlich erst mal nicht so.

Die Daten kommen an und werden anhand der Filterregeln den Usern/Clients zugeordnet (eigene Tabelle mit UserID, DatenID).
Der Client wird informiert, dass da etwas neues für ihn vorhanden ist und der Client holt dann die Daten ab. Nach dem Abholen wird der Eintrag aus der Tabelle entfernt.

Sollen die Informationen, welcher Client welche Daten bekommen hat gespeichert werden, dann in diese Tabelle um ein Flag (Bool oder DateTime nach Belieben) erweitern.
Damit weiß der Server alles was notwendig ist und der Client braucht nichts mitzuteilen, nur zuhören und abholen.

[Medium]

Gut, das wäre dann, wenn der Client direkt auf die DB zugreifen kann/darf. Ich meine aber, dass der TE das ausgeschlossen hat, und auch die Nutzdaten komplett über die Middleware fließen müssen.

[Sir Rufo]

Zitat:

Zitat von Medium (Beitrag 1157942)

Gut, das wäre dann, wenn der Client direkt auf die DB zugreifen kann/darf. Ich meine aber, dass der TE das ausgeschlossen hat, und auch die Nutzdaten komplett über die Middleware fließen müssen.

Wieso das denn?

Ob die Client-App die Server-App fragt, und die Server-App daraufhin den SQL-Server fragt, wo ist da der Unterschied, als ob die CLient-App den SQL-Server direkt fragen würde?

Keiner, ist eben nur (aus Sicherheitsgründen) eine Zwischenschicht.

[romber]

Zitat:

Zitat von Medium (Beitrag 1157942)

Gut, das wäre dann, wenn der Client direkt auf die DB zugreifen kann/darf. Ich meine aber, dass der TE das ausgeschlossen hat, und auch die Nutzdaten komplett über die Middleware fließen müssen.

Die Middleware stammt aktuell auch von mir, ich kann dort nach Bedarf uneingeschränkt rumfummeln. Ich habe da aber eine ganz andere Sorge. Nehmen wir an, der Server soll die Clients über die Neuzugänge benachrichtigen. In diesem Fall stellt der Client eine Verbindung zum Server her, haltet diese permanent aufrecht, lässt diese von einem zusätzlichen Thread überwachen und wartet auf die Benachrichtigungen des Servers. Wenn die neue Datensätze vorhanden sind, hollt der Client diese ab. Dafür wird seitens Middleware (mit der der Client eigentlich verbunden ist) die Anfrage an die von Sir Rufo vorgeschagene Zwischentabelle geschickt, die alle neue für den aktuellen Client bestimmte Datensätze zurückliefert und an den Client weiterleitet. Meine Frage ist: wird es nicht schneller, wenn der Server anstatt den Client zu Benachrichtigen den Datensatz direkt an den Client weiterleitet? So wird eine DB-Abfrage und somit auch die wertvolle Zeit gesparrt. Wäre das nicht schneller?