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

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

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 von Medium:

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 von Sir Rufo:

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 von Sir Rufo:

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 von mjustin:

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 von romber:

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 von romber:

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 von 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.

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.

[Medium]

Zitat von Sir Rufo:

wo ist da der Unterschied[...]?

Man würde sich sparen können, das eigene Protokoll um das dann nötigene Durchreichen des SQL Datentransfers zu erweitern. Nicht viel, aber immerhin

Rombers Einwand ist, wenn die Middleware ohnehin davon ausgehen kann, dass ein Notify von einem Request gefolgt wird, berechtigt. Dann doch gleich den ganzen Payload absetzen.

[romber]

Zitat von 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.

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?

[mjustin]

Zitat von romber:

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?

Vorausgesetzt der Client ist gerade nicht durch andere Aufgaben stark ausgelastet, und die Datensätze kommen nicht zu schnell an, ist das sicher eine Option.

Der Server muss aber möglicherweise den Datensatz erst einmal speichern und wieder auslesen bevor er ihn zum Client sendet, falls Trigger oder andere Automatismen in der Datenbank den Satz verändern können (zum Beispiel Defaultwerte die beim Insert von NULL Werten aktiv werden).

Was aber macht der Server wenn die Clientverbindung während der Übertragung abbricht? Message Broker Clients können Nachrichten auch transaktional empfangen, oder je Nachricht ein "Acknowledge" senden damit der Server die Übertragung als erfolgreich ansieht. Die Nachricht wird dann so lange gesendet bis der Client sie erhalten hat ("Guaranteed Delivery"), optional sogar wenn der Client zwischendurch offline war.

Im konkreten Anwendungsfall hätte es aber einen Nachteil, die Datensätze komplett zu senden: wenn der Client die Nachricht erst mit Verspätung erhält, zum Beispiel weil ein ganzer Stapel auf einmal eintrifft, ist die letzte Nachricht möglicherweise schon nicht mehr auf dem aktuellen Stand. Die Gefahr veralteter Daten ist geringer, wenn man die Datensatz-ID in die Nachricht mit aufnimmt, und den Client damit in die Lage versetzt auf den aktuellen Stand des Satzes zuzugreifen.

Hier ist ein Pseudocodebeispiel wie ein Message Broker die (gefilterten) Nachrichten an den Client sendet. Es geht davon aus, dass eingehende Aufträge nach Postleitzahlgebieten den Mitarbeitern zugeordnet werden.

Code:

Client: CONNECT (meldet sich an mit Benutzer / Password)
Server: CONNECTED

Code:

Client: SEND "Hallo Server, bitte konfiguriere mich!"
Server: MESSAGE Ihre Postleitzahlgebiete sind: QUEUE4A=PLZ40000-44999, QUEUE6=PLZ60000-69999

Der Client wählt, welche Queues (Auftragswarteschlangen) er bearbeiten möchte:

Code:

Client: SUBSCRIBE QUEUE4A
Client: SUBSCRIBE QUEUE6

Der Client kann jetzt (in einer Schleife in einem Backgroundthread) auf neue Nachrichten prüfen. Das Prüfen ist dabei kein Polling, sondern nur ein Überwachen des TCP Sockets auf eintreffende Pakete. Der Client kann einen Timeout angeben und bei einem Kommunikationsfehler erneut mit dem Server verbinden.

Sobald ein neuer Auftrag eintrifft, sendet der Server ihn an die jeweilige Queue:

Code:

Server: MESSAGE ID=123, Auftrag="12356", (weitere Daten)
Client stellt Daten in GUI dar und besätigt Empfang:
Client: ACK 123

Durch das ACK erfährt der Server, dass der Client die Daten erhalten und bestätigt hat. Das ist sehr wichtig, da Senden über TCP/IP nicht heisst, dass der Client die Daten empfangen hat.


Diese Aufteilung auf "Queues" ist auch eine einfache Lösung für den Fall, dass zwei Mitarbeiter den gleichen Postleitzahlenbereich bearbeiten, aber ein Auftrag immer nur von einem Mitarbeiter zur Bearbeitung angenommen werden darf.
Denn das ist ein Merkmal der "Queues" in einem Message Broker: es wird maximal nur ein Client die Nachricht erhalten. Die Aufträge für ein PLZ-Gebiet werden dadurch automatisch auf alle angemeldeten Clients verteilt, die sich an dieser Queue registriert haben. Falls der Empfang oder die Verarbeitung der Nachricht scheitert und der Server kein ACK erhält, wird die Nachricht dem nächsten passenden Client zugestellt.

[romber]

Zitat von mjustin:

Denn das ist ein Merkmal der "Queues" in einem Message Broker: es wird maximal nur ein Client die Nachricht erhalten. Die Aufträge für ein PLZ-Gebiet werden dadurch automatisch auf alle angemeldeten Clients verteilt, die sich an dieser Queue registriert haben. Falls der Empfang oder die Verarbeitung der Nachricht scheitert und der Server kein ACK erhält, wird die Nachricht dem nächsten passenden Client zugestellt.

Das ist aber sicher ein optionales Merkmal, den man bei Bedarf ausser Kraft setzen kann, oder? Denn genau das möchte ich vermeiden. Jeder Client, der den Datensatz braucht, muss ihn auch komplett erhalten.