Design Problem mit Client-Server Kommunikation

Hi,

also ich habe folgendes Problem:
Ich habe mehrere Clients und einen zentralen Server. An den zentralen Server werden von irgendwo laufend UDP Pakete gesendet. Er nimmt sie auf, bearbeitet die Infos in den UDP-Paketen und speichert sie in eine Datenbank. Gleichzeitig sollen aber die Clients auch diese bearbeiteten Infos bekommen.
Welche Möglichkeiten für die Kommunikation zwischen Client und Server gibt es da ?

  1. Ich könnte eine Connection zwischen Client und Server aufbauen. Wenn der Server eine neue Info kriegt schickt er einfach die Infos an die Clients über den Kanal.
  2. Ich mache das Ganze mit RMI. Da müsste der Client aber dauernd beim Server „nachfragen“, ob neue Infos anliegen (Ist das die Push-Technologie ?). Das Problem hierbei ist, dass die Clients Infos „verpennen“ können.
  3. Ich wollte ursprünglich das Ganze über SOAP machen, da der Client dann auch hinter einer Firewall sein kann. Ich hätte aber das Gleiche Problem wie bei RMI. Zudem kommt noch, dass wenn es viele Clients sind, den Server durch dauernde Nachfrage evtl. zu stark belasten.

Hat jemand eine Idee, wie ich es am besten mache ?

Danke und viele Grüße,

Tristan.

Es gibt zig Möglichkeiten, z.b. könnte der „Client“ auch auf einen UDP Port lauschen und dort Infos vom zentralen Server geschickt bekommen.

Die beste Lösung hängt vom Anwendungsfall ab, was hast du da genau vor? Wichtig ist vor allem auch wie schnell / oft / wieviel Daten da geschickt werden. Muss das möglichst in Echtzeit geschehen oder reicht es alle paar Sekunden / minuten? Und so weiter… Bitte mehr Infos um dies vernünftig beantworten zu können.

Grüße
Bruno

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo Bruno,

Es gibt zig Möglichkeiten, z.b. könnte der „Client“ auch auf
einen UDP Port lauschen und dort Infos vom zentralen Server
geschickt bekommen.

aber dafür müsste der Server alle Adressen von den Clients kennen, oder ? Die müssten die Clients dem Server mitteilen.

Die beste Lösung hängt vom Anwendungsfall ab, was hast du da
genau vor? Wichtig ist vor allem auch wie schnell / oft /
wieviel Daten da geschickt werden. Muss das möglichst in
Echtzeit geschehen oder reicht es alle paar Sekunden /
minuten? Und so weiter… Bitte mehr Infos um dies vernünftig
beantworten zu können.

Also es handelt sich um eine Verteilte Anwendung für eine Bibliothek. In der Bibliothek geben Benutzer Suchbegriffe ein und diese werden vom Web-Server abgefangen in Form von UDP Paketen. Die Suchbegriffe sollen zugleich gespeichert und möglichst in Echtzeit an die Clients geschickt werden, die die Suchbegriffe dann darstellen.
Was würdest Du von einer URLConnection von Server zu Client halten ?

Viele Grüße,

Tristan

  1. Ich könnte eine Connection zwischen Client und Server
    aufbauen. Wenn der Server eine neue Info kriegt schickt er
    einfach die Infos an die Clients über den Kanal.

Falls diese Benachrichtigungen sehr häufig vorkommen, würde ich diese Möglichkeit wählen, also TCP-Verbindungen zwischen den Clients und dem Server aufbauen und permanent aufrechterhalten.
Jeder Client würde einen Socket zum Server öffnen und für den Rest seines Lebenszyklus daran horchen. Der Server müsste dann die Benachrichtigungen jeweils über alle auf seiner Seite offenen Sockets rausschicken.
Auf diese Weise müsste serverseitig keine Liste von Client-Adressen verwaltet werden, der initiale Verbindungsaufbau geht ja vom Client aus.

Falls die Benachrichtigungen aber nur im Minuten- oder gar Stundenrhythmus rausgehen, würde ich die Clients per E-Mail benachrichtigen. :wink:

Servus
Tom

Moin

aber dafür müsste der Server alle Adressen von den Clients
kennen, oder ? Die müssten die Clients dem Server mitteilen.

Naja… Anworten auf Suchanfragen werden in der Regel nur an den Client verschickt der gefragt hat, somit muss der Server gar nichts wissen.

(Der Server

Also es handelt sich um eine Verteilte Anwendung für eine
Bibliothek. In der Bibliothek geben Benutzer Suchbegriffe ein
und diese werden vom Web-Server

gutes Stichwort… schonmal an einen normalen http-server mit jsp gedacht ?

abgefangen in Form von UDP Paketen.

UDP = Unzuverlässig. Dann musst du time-outs in Clients und Server einbauen, mit resend und Kontrolle und Protokoll… nimm TCP.

Die Suchbegriffe sollen zugleich gespeichert und
möglichst in Echtzeit an die Clients geschickt werden, die die
Suchbegriffe dann darstellen.

Eigentlich muss nur der Client die Anwort bekommen der die Frage gestellt hat.

Was würdest Du von einer URLConnection von Server zu Client
halten ?

Ich würd TCP für alle Verbindungen benutzen. Suchergebnisse in einer Bib werden das Netzwerk schon nicht überlasten und das Schreiben von Timeout und resend ist es nicht wert. Auf dem Server dann einen Theard pro Client laufen lassen. Die Daten in einer SQL-DB speichern … Ist doch eigentlich ganz einfach.

cu

Hallo,

danke für die Antwort.

Falls diese Benachrichtigungen sehr häufig vorkommen, würde
ich diese Möglichkeit wählen, also TCP-Verbindungen zwischen
den Clients und dem Server aufbauen und permanent
aufrechterhalten.

Die Frequenz der Benachrichtigungen hängt denke ich mal von der Tageszeit ab, da zu bestimmten Zeiten mehr Leute in der Bibliothek suchen.

Jeder Client würde einen Socket zum Server öffnen und für den
Rest seines Lebenszyklus daran horchen. Der Server müsste dann
die Benachrichtigungen jeweils über alle auf seiner Seite
offenen Sockets rausschicken.
Auf diese Weise müsste serverseitig keine Liste von
Client-Adressen verwaltet werden, der initiale
Verbindungsaufbau geht ja vom Client aus.

Das ist richtig. Nur ist der Nachteil nicht, dass der Server für jeden Client einen Socket braucht ? Was ist, wenn tausende von Clients installiert werden ?
Ein anderer Nachteil ist doch, dass wenn sich der Client hinter einer Firewall befindet, das dann nicht mehr funktioniert, oder ?

MfG,

Tristan.

Hallo,

danke für die Antwort.

aber dafür müsste der Server alle Adressen von den Clients
kennen, oder ? Die müssten die Clients dem Server mitteilen.

Naja… Anworten auf Suchanfragen werden in der Regel nur an
den Client verschickt der gefragt hat, somit muss der Server
gar nichts wissen.

Das bezog sich eigentlich auf die UDP-Lösung von Bruno. D.h. der Server verschickt die Infos auch wieder als UDP-Pakete an die Clients. Dafür müsste er aber die Adressen von den Clients kennen.
Die Clients könnten diese natürlich vorher kurz mitteilen, aber das Problem ist wieder wenn der Client sich hinter einer Firewall befindet.
Übrigens, nochmals zur Wiederholung: Die UDP-Pakete, die zum Server geschickt werden und in der sich die Infos für die Suchanfragen befinden, kommen von den Bibltiotheksrechnern. Der Server schickt die Infos dann weiter an Clients, die ich schreiben muss. Ich weiss nur nicht, wie ich es am besten mache mit der Server-Client-Connection, weil cih auch in Betracht ziehe, dass sich die Clients hinter einer Firewall befinden können.

Viele Grüße,

Tristan.

Das ist richtig. Nur ist der Nachteil nicht, dass der Server
für jeden Client einen Socket braucht ?

Jupp.

Was ist, wenn tausende von Clients installiert werden ?

Dann kriegst du so oder so ein Performance-Problem.

Ein anderer Nachteil ist doch, dass wenn sich der Client
hinter einer Firewall befindet, das dann nicht mehr
funktioniert, oder ?

Das hängt natürlich davon ab, wie die Firewall konfiguriert ist. :smile:
Theoretisch spricht nichts dagegen, die Verbindungsaufnahme der Clients über Port 80 zu machen - sofern der fragliche Server nicht gleichzeitig als Webserver dient.

Servus
Tom

Moin

danke für die Antwort.

bitte.

Naja… Anworten auf Suchanfragen werden in der Regel nur an
den Client verschickt der gefragt hat, somit muss der Server
gar nichts wissen.

Das bezog sich eigentlich auf die UDP-Lösung von Bruno. D.h.
der Server verschickt die Infos auch wieder als UDP-Pakete an
die Clients. Dafür müsste er aber die Adressen von den Clients
kennen.

Die Addresse des Fragestellers steht doch in dem ankommenden UDP-Packet.

Die Clients könnten diese natürlich vorher kurz mitteilen,
aber das Problem ist wieder wenn der Client sich hinter einer
Firewall befindet.

Bei Firewalls ist TCP wesentlich besser. UDP wird von vielen Firewalls einfach geschluckt.

Übrigens, nochmals zur Wiederholung: Die UDP-Pakete, die zum
Server geschickt werden und in der sich die Infos für die
Suchanfragen befinden, kommen von den Bibltiotheksrechnern.
Der Server schickt die Infos dann weiter an Clients, die ich
schreiben muss.

ähm:

Client1
Client2
Client3 -----\>UDP----\>Bibltiotheksrechnern ---\>UDP---\>SERVER----\>UDP ---\>Clients
Client4

Ich weiss nur nicht, wie ich es am besten
mache mit der Server-Client-Connection,

welcher Teil ist das, welche Rechner haben welche Daten die welche anderen Rechner haben wollen ?

weil cih auch in
Betracht ziehe, dass sich die Clients hinter einer Firewall
befinden können.

Firewall und UDP verträgt sich nicht…

(Zu deiner anderen Antwort: wenn du mit tausenden Rechnern rechenst, dann bau time-out’s ein. Inaktive Verbindungen werden einfach getrennt. Ausserdem sind 1000ed Rechner unrealistisch. Wenn du von 1000 innerhalb von 5 min Suchanfragen bekommst ist ein einzelner Rechner tot, egal wer Server spielt.)

cu

Klingt alles bischen seltsam :smile: Wieso müssen Clients darstellen was ein anderer irgendwo sucht? Naja egal, interessant wäre auch noch wie wichtig die Zuverlässigkeit ist, wenn da nur was dargestellt wird, geh ich mal davon aus dsas es auch nicht so schlimm ist wenn mal was verloren geht (sprich UDP).

Mit deiner Firewallproblematik wär das beste natürlich wenn du über HTTP gehst (z.b. SOAP oder sowas).

Grüße
Bruno