Rat für Umsetzung Client-Server-Architektur gesucht

**Jumpy**

Hallo DP,
der zweite Versuch

:

Ich soll als Azubi-Übungs-Projekt eine kleine Client-Server-Anwendung schreiben und hab noch keine Ahnung, wie ich ansetzen soll. Ich habe mir schon einige Beispiele hier angesehen (hauptsächlich Chats, da das glaub ich dem was ich brauche am nächsten kommt), die mich zum Teil aber auch verwirrt haben, da z.B. auch die Clients nachher Server-Komponenten hatten.

Es soll eine zentrale Anwendung geben, die auf einem eigenen Rechner im lokalen Netzwerk läuft und eine Liste zusammenstellt bzw. ständig aktualisiert. Das wird eine einfache TStringlist sein mit vllt. max. 200 Strings drin. Diese hat nix mit den Clients zu tun. Es geht um Daten aus der TK Anlage, nicht sensitiv, daher muss nix verschlüsselt werden.

Die Clients sollen nun auf allen anderen Rechnern des Netzwerkes laufen können und diese Liste anzeigen.

Ich hab mir da naiv 3 mögliche Grundaufbauten überlegt und bräuchte Beratung welche davon ich nehmen soll, wenn ihr nicht sogar noch was besseres kennt, dass mir nicht eingefallen ist.
Wenn dann ein Grundaufbau feststeht, bräuchte ich dann noch Tipps, wie man diesen (mit welchen (kostenlosen!!!) Komponenten) realisieren könnte.

Szenario1:
Ein Client wird gestartet und meldet sich beim Server an. Wird der Client beendet, so meldet er sich natürlich auch wieder beim Server ab. Sobald der Server seine Liste aktualisiert hat pusht er sie an alle Clients, die bei ihm angemeldet sind. (So ein bißchen wie ein rss feed?)
Untervariante:
Die aktuelle Liste wird in eine DB geschrieben und der Server pusht dann nur eine Info, dass eine neue Liste vorliegt und die Clients holen sie sich dann aus der DB ab.

Szenario2:
Die Clients sind dem Server nicht bekannt, stattdessen fragen sie timergesteuert immer wieder die aktuelle Liste beim Server an, der Sie dann zurückschickt (so wie der browser eine Webseite immer wieder neu anzeigt, wenn der user alle paar Sekunden auf aktualisieren klickt).

Szenario3:
Client und Server haben gar nix miteinander zu tun. Der Server schreibt die aktuelle Liste in eine DB und die Clients fragen timergesteuert immer die DB ab.

Szenario 2 und 3 gefallen mir nicht so, wegen dem Stichwort Timergesteurt. Ist nämlich das Intervall zu groß gewählt, so kriegen die Clients manche Änderungen vllt. gar nicht mit. Ist es zu klein gewählt, werden Netztwerk und/oder DB mit ständigen Abfragen belastet. Gerade die Belastung von Ressourcen soll vermieden werden, da das nämlich der momentane Stand ist: Es gibt nämlich aktuell nur Clients, die sich alle an die TK-Anlage hängen und diese belasten.

Ich würde, wenn ihr mir nichts anderes ratet auf Szenario 1 setzen und zwar wahrsch. ohne die DB-Variante. Desweiteren wäre die Überlegung nicht immer die ganze Liste zu senden, sondern nur Aktualisierungen, um die zu sendende Datenmenge zu verringern. Vllt. gelegentlich mal die ganze Liste um Synchronität zu gewährleisten?

Welche Komponenten müsste ich denn dann benutzen und wie überträgt man dann die Nutzdaten. Muss ich da irgendwie ein eigenes Netzwerkprotokoll entwickeln? Das ist doch wahrsch. overkill, oder?

**ensaron**

Hallo,

was Client-Server-Systeme angeht bin ich zwar noch nicht sonderlich erfahren, aber zumindest ein paar Ansatzpunkte kann ich dir evtl liefern ^^

Zu den Komponenten: Da dürften die Indy-TCP-Komponenten das sein, was du suchst:

http://www.indyproject.org/Sockets/index.DE.aspx

Die Nutzdaten werden dabei über das Transmission-Control-Protocol (TCP) übertragen.

Zum Vorgehen:
Da würde ich auch Szenario 1 ohne DB verwenden.
Um Änderungen den Clients bekannt zu machen, wirst du dann aber noch Callbacks brauchen, damit der Server von sich aus die Clients kontaktieren kann. Normalerweise sitzt der Server ja nur ganz still da und wartet darauf, dass ein Client was von ihm möchte.
Denke das wird auch der Grund sein, warum die Clients in den von dir erwähnten Beispielen Server-Komponenten beeinhalten - damit sich der Server bei den Clients melden kann, ohne Callbacks zu nutzen. Somit wird der Server dann quasi temporär zum Client, der sich nacheinander bei den Servern meldet, die eigentlich seine Clients sind (hoffe das war jetzt verständlich und sachlich korrekt wiedergegeben

). Kommt mir aber nicht wirklich sauber vor ^^

Zu den Details der Umsetzung kann ich leider nicht viel beitragen, da ich sowas noch nicht selbst programmiert hab. Aber vielleicht helfen dir die Ansätze ja schonmal weiter.

**mjustin**

Zitat von Jumpy:

Welche Komponenten müsste ich denn dann benutzen und wie überträgt man dann die Nutzdaten. Muss ich da irgendwie ein eigenes Netzwerkprotokoll entwickeln? Das ist doch wahrsch. overkill, oder?

Die Option 1 scheint mir auch die passendste zu sein. Wenn es kein Peer-to-Peer Chat (ohne zentralen Server) sein muss, werden auf der Clientseite keine Serverkomponenten benötigt. Denn über eine einmall hergestellte TCP/IP Socketverbindung kann man sowohl senden (Client->Server) als auch empfangen (Server->Client), auch "gleichzeitig", wenn man zum Lauschen auf die Servernachrichten einen Thread verwendet.

Ein Protokoll, das dem nahe kommt ist Telnet. In der Indy-Komponentensammlung ist ein Telnet Client (TIdTelnet) und auch ein Telnet Server, der Client benutzt eine Unterklasse von TIdThread um Servernachrichten zu lesen und asynchron zu verarbeiten, dabei wird diese Nachrichtenverarbeitung über Synchronize mit dem Hauptthread synchronisiert.

Telnet ist natürlich nur ein spezieller Anwendungsfall, man kann die Indy Komponenten aber als Ausgangspunkt nehmen.

Ein verbreitetes Protokoll, das Text- und Binärdaten zwischen Clients effizient, auch mit Server-Push, austauschen kann ist

STOMP. Open Source Client und Server Implementierungen findet man im Internet.

**jobo**

trotz roter Box, meine Gedanken:
Wie werden denn die TK Anlagen Werte bereitgestellt? Echtzeit? Zyklus? Das dürfte doch irgendwie relevant sein für die Frage Polling.
Sollen Differenzmengen an den Client gegeben werden? Dann darf natürlich nichts geschlabbert werden. Andernfalls: Ist es schlimm wenn mal was fehlt? Kommt sicher auf das realisierte Durchschnittsinterval an. Infos die alle 10 Sekunden aktualisiert werden, dürfen sicher lückenhaft sein (bspw. welche Telefone sind besetzt, welche frei). Ist das Interval 5 Minuten oder größer, sind verpasste Änderungen natürlich unschön.
Last:
Für einen Echtzeitabgleich (kein Polling) kann ebenfalls eine große Last entstehen, wenn der Server ständig "kleinste" Änderungen in Form neuer Gesamtlisten verteilt. Wenn er dabei auf überlastete Clients warten muss, erst recht.
Eine timergesteuerte Abfrage (Polling) könnte ich mir gut vorstellen, wenn man vielleicht noch eine Dirty Flag, Timestamp oder so verwaltet (für Differenzbetrachtung) und das Timing so steuert, dass nicht doch wieder alle auf einmal abfragen (Timerinitialisierung/-handhabung muss zeitliche Gleichverteilung der Abfragen sicherstellen), also "gezielt" streut.
DB:
Scheint mir ein dicker Overhead für den Anwendungsfall (Lizenzen, Login, Userverwaltung ...)

**Angel4585**

Ein Gedanke aus eigener Erfahrung:
Serverkomponente beim Client ist doof

Wenn der eigentliche Server eine zweite Verbindung zum Client braucht sollte diese auch vom Client aus aufgebaut werden.
Je nachdem wie bzw. wo die Client-Anwendung eingesetzt werden soll.
Wird die Anwendung bei Heimanwendern benutzt hat man Probleme wenn ein Server eine Verbindung zum Client aufbauen soll, weil er in der Regel bei der Firewall vom Router des Heimanwenders hängenbleibt.

Entweder eine einzige Verbindung nutzen oder eine zweite vom Client zum Server aufbauen und durch ein einfaches Protokoll dem Server mitteilen welche jetz zum lesen und welche zum schreiben ist.
Allerdings habe ich in Erinnerung, dass eine Verbindung völlig genügt.

**Jumpy**

Erstmal danke für die Beiträge.

@ensaron: Das mit den Servern im Client usw. war genau das was ich meinte, danke für die Erklärungen. Das mit den Callbackfunktionen muss ich mir mal näher ansehen, wie sowas funktioniert, das könnte was sein, denn:

@jobo: Die TK-Anlage wird mittels TAPI überwacht, indem der Server da eine Callbackfunktion anmeldet, über die er dann bei jeder Statusänderung bei jeder Telefonleitung (Line) Bescheid bekommt.
Diese Änderungen werden dann gefiltert, und nur wenn eine Interessante kommt, z.B. Nr. 5 telefoniert gerade, wird das in die Liste mit aufgenommen.
Was die Menge der Daten angeht, dachte ich daran, nur eine - wie hast du es genannt - Differenzmenge zu schicken und nur bei jeder Xten Änderung dann mal alles komplett zu schicken. Und vllt. auch wenn sich ein neuer Client angemeldet hat.

@angel: alles nur im lokalen Netz.

@mjustin: Telnet und Stomp werd ich mir mal ansehen. Stomp Clients gibts ja reichlich, aber Server wird wohl was schwerer.

**Sir Rufo**

Zum Konzept fällt mir erst mal folgendes ein:

Wenn der Server einen aktiven Kanal zum Client hat, dann sollte der Server damit nicht die Daten schicken, sondern eine Benachrichtigung, dass es mittlerweile neue Daten gibt. Der Client teilt dann mit, was er schon hat und bekommt dann alles das, was neuer ist.

Dieses Konzept hat schon mal entscheidende Vorteile:

dieser aktive Rückkanal braucht zunächst nicht implementiert werden
Der Server braucht sich nicht zu merken, was der Client alles wissen müsste

Als Client/Server könntest du

mORMot benutzen. Da ist alles schon enthalten (Client/Server-Protokoll, Datenbank, Sicherheit, etc.) - bis auf den aktiven Rückkanal.

Ein Beispiel gibt es auch hier im Forum Delphi-Referenz durchsuchen

mORMot

**Jumpy**

Ein kleines Statusupdate:

Ich hab mal eine erste Testversion, bei der nur Dummy-Daten verschickt werden aufgebaut. Dabei hab ich mir das

Chat-Tutorial von Ultimator als Vorlage genommen und leicht abgewandelt.

Das ganze in Delphi6 und mit den Komponenten TServerSocket und TClientSocket.

Fazit, das funktioniert wie gewünscht und würde mir schon reichen, doch habe ich u.a. hier im Forum gelesen, dass bei neueren (Server-)Betriebssystemen ein ServerSocket nur noch 10 Clients akzeptiert. Ist da was dran, oder hab ich das Missverstanden?
Ich teste das z.Zt. mit XP und da ging es. Da aber noch nicht klar ist, auf welchem Server das nachher läuft, mach ich mir sorgen, dass das nachher in der Echtanwendung nicht mehr funzt.

Für diesen Fall hab ich mir einen Plan B überlegt und wollte mal fragen, ob der sinnvoll ist. Ich baue den Server mit mehreren TServerSocket-Komponenten, die jeweils an einem anderen Port lauschen (geht das)? Der Client verbindet sich zunächst mit einem zentralen ServerSocket (quasi ein Verwalter), dass dem Client als einzige Info dann nur den Port schickt, an dem eine "Socket lauscht" die noch freie Kapazitäten hat und mit dieser verbindet sich dann der CLient.

**mjustin**

Zitat von Jumpy:

..., dass bei neueren (Server-)Betriebssystemen ein ServerSocket nur noch 10 Clients akzeptiert. Ist da was dran, oder hab ich das Missverstanden?
Ich teste das z.Zt. mit XP und da ging es.

Bei Serverbetriebssystemen gibt es ganz sicher keine Begrenzung. Auf XP (ein Clientbetriebssystem) bezogen habe ich diesen Link gefunden:

Windows XP SP2 TCP Connection Limit (Event ID 4226) - XP erlaubt maximal zehn Verbindungen pro Sekunde, damit soll laut Angaben die Verbreitung von Viewn ("Würmern") gebremst werden, es gibt im Internet viele Seiten die Software zur Lösung dieses "Problems" anbieten (Disclaimer: der dort angebotene Download soll angeblich die Grenze beseitigen, ich rate aber dazu Anwendungen aus unsicheren Quellen nicht herunterzuladen und auszuführen)

Ob es lizenzseitig gestattet wird, auf einem Clientbetriebssystem wie XP vielen anderen Benutzern einen Zugang zu ermöglichen ist eine andere Frage

**Jumpy**

Ich hab es wie folgt getestet:
Mein Desktop PC XP SP3 beherbergt die Serveranwendung und es laufen 4 Clients auf ihm.
Desktop PC meines Kollegen, Win7, beherbergt 4 weitere Clients.
Eine VM, die auf einem Server liegt, Win 7, beherbertg nochmal 4 Clients.

Insgesamt also 12 Clients. Und es gab keine (sichtabren) Probleme.
Kann natürlich sein, da sich die 12 Clients auf nur 3 IP-Adressen verteilen, dass es daher klappt?

Und wie gesagt, ich nutze keine TCP-Komponenten, sondern TServersocket und TClientSocket.