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

[Medium]

Zitat:

Zitat von Sir Rufo (Beitrag 1157946)

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.

[mjustin]

Zitat:

Zitat von romber (Beitrag 1157951)

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:

Zitat von mjustin (Beitrag 1157972)

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.

[mjustin]

Zitat:

Zitat von romber (Beitrag 1158047)

Zitat:

Zitat von mjustin (Beitrag 1157972)

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.

Ja, eine Verteilung einer Nachricht an mehrere Empfänger ist natürlich möglich:

* man legt eine Queue pro Empfänger an, oder
* man verwendet einen "Topic", Nachrichten, die an einen Topic gesendet werden, werden an alle angemeldeten Empfänger gesendet, dabei kann auch mit Selektoren weiter gefiltert werden

[romber]

Da bin ich wieder mit meinen Problemen :-)
Diese Message Broker Geschichte ist eine coole Sache, jedoch braucht es seine Zeit, bis man richtig damit ungehen kann. Ich bleibe dran, möchte aber erstmal versuchen, mein Vorhaben mit "herkömmlichen" Mitteln zu realisieren. Wenn ich dann mit MB soweit bin, kann man ja immer eine neue Version herausbringen und dabei vielleich noch bisschen in die Tasche zu legen ;-)

Ich habe mich erstmal für folgendes Modell entschieden: Der Client stellt eine dauerhafte überwachte Verbindung mit dem Server her und wartet auf die Benachtichtigungen des Servers. Kommt eine Benachrichtigung an, holt der Client die für ihn bestimmte Daten ab. Dafür steht serverseitig eine Tabelle mit UserID, DatenID bereit, so wie Sir Rufo und Medium das vorgeschlagen haben. Dazu eine Frage. Und zwar ein Datensatz passt zu mehreren Filtern von verschiedenen Clients. Der Server muss alle betroffene Client benachrichtigen? Kann ich eine Nachricht wirklich gleichzeitig an mehrere Clients senden oder komme ich an einer Schleife nicht vorbei?