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?