Wie findet der Client seinen Server?

[Jumpy]

Hallo,

ich schreibe gerade ein Programm, das sowohl als Server als auch als Client arbeitet. Der erste der das Programm startet soll es als Server starten, alle späteren als Client, die sich mit dem Server verbinden.

Ähnlich wie es bei Spielen wie CS ist, wo einer einen Server "aufmacht" mit dem sich die anderen Spieler dann verbinden.

Wie macht man das, das die Clients den Server finden? Der kann ja immer auf einem anderen Rechner gerade laufen?

[RedOne]

Mache einen Broadcast (an IP 255.255.255.255). Dann wird eine Message an alle PC's versandt. Der Server meldet sich dann zurück und schon weisst Du, wo der Server liegt.
Wenn das ganze aber übers Internet läuft, dann brauchst Du einen "Masterserver", bei dem sich die einzelnen Server registrieren müssen.

[mjustin]

Der Server macht einen UDP Broadcast, alle Clients erhalten dann seine Nachricht.

In der Nachricht kann der Server seinen Hostnamen angeben, unter dem die Clients ihn erreichen.

Wie die Clients UDP (IP Multicast als Beispiel eines Broadcast) verwenden können, habe ich hier beschrieben:

Discover ActiveMQ brokers with Delphi and IP Multicast

Was noch fehlt ist der Code der vom Server aus UDP Broadcasts versendet, das sollte aber mit Indy leicht sein.

[BUG]

Hier gibt es im Grunde 2 Möglichkeiten:

Broadcasten (über UDP):
Hier ruft entweder der Server ständig ins Netz oder die Clients fragen nach, wenn der Server gesucht wird. Dies funktioniert nur in lokalen Netzen ((W)LAN).

Anfragen an eine wohlbekannte Adresse:
Du fragst das DNS (DynDNS) oder betreibst selbst einen Server unter wohlbekannter Adresse, bei dem sich die richtigen Server anmelden können.


Wenn du selbst keinerlei Infrastruktur betreiben möchtest, funktioniert nur das erste.
Mit ein bisschen Einarbeitung könntest du zB. kostenlos die Google App Engine nutzen, um Server zu verwalten.

[Jumpy]

Das ganze soll nur innerhalb eines LANs stattfinden, also reicht mir eine einfache Variante.
Bei der "Server broadcasted per UDP"-Variante. Wie oft macht der das? Erzeuge ich nicht so unnötige Netzwerklast?

Zitat:

Zitat von BUG (Beitrag 1209859)

Broadcasten (über UDP):
... oder die Clients fragen nach, wenn der Server gesucht wird. Dies funktioniert nur in lokalen Netzen ((W)LAN).

Wie würde ich das genau umsetzen? Mit welchen Komponenten? Ich hab meine Client-Server-Geschichten bisher immer mit den Socket-Komponenten gebaut, die bei Delphi dabei sind. Das waren aber immer fälle, wo die IP des Servers bekannt war oder aus einer Datenbank oder Ini gelesen wurden.

[mjustin]

Zitat:

Zitat von Jumpy (Beitrag 1209864)

Das ganze soll nur innerhalb eines LANs stattfinden, also reicht mir eine einfache Variante.
Bei der "Server broadcasted per UDP"-Variante. Wie oft macht der das? Erzeuge ich nicht so unnötige Netzwerklast?

Das ideale Intervall ist natürlich anwendungsabhängig. Der ActiveMQ Server sendet zirka im Sekundentakt, das UDP Paket ist nur wenige Bytes lang. Das wird die Trafficabrechnung kaum erhöhen:)

[jfheins]

Ich würde trotzdem die "Client broadcastet, Server antwortet" Lösung empfehlen.

Zur Umsetzung: Du kannst den TIdUDPServer + TIDUDPClient hernehmen, damit sollte sich was basteln lassen. und für die richtige Kommunikation wäre dann TCP angebracht.

[mjustin]

Zitat:

Zitat von jfheins (Beitrag 1209870)

Ich würde trotzdem die "Client broadcastet, Server antwortet" Lösung empfehlen.

Die Netzwerklast wird damit proportional zur Anzahl Clients steigen. Auch wird der Server entsprechend zur Anzahl Clients entsprechend mehr Last zur Beantwortung der Broadcasts verursachen, während bei Server-Broadcast die Serverlast unabhängig von der Anzahl Clients ist. (Angenommen, wir hätten eine Umgebung mit einer relevanten Anzahl Clients, nicht nur zwei oder drei...). Wo ist der Vorteil gegenüber einem Server-Broadcast?

[Phoenix]

Ich finds ja immer wieder erstaunlich, wie oft so ein olles Rad neu erfunden werden soll.

Das ganze Broadcast-Zeug ist zwar prinzipiell sehr einfach, aber der Teufel steckt im Detail (Wahl der Intervalle, die Frage wer pollt und wer antwortet etc., was passiert wenn zwei Clients gleichzeitig im Netz aufploppen - wer aktiviert den Server?).

Die ganze Thematik Service Discovery / ZeroConf (Zero Configuration Networking) ist aber schon in aller Erschöpfung vollumfänglich mehrfach abgenudelt.

Die Grundlegenden Protokolle sind dabei DNS-DS (Apple's Bonjour bzw. ZeroConf) bzw. SLP.
Apple liefert für Bonjour ein SDK mit, so dass man das direkt verwenden kann (gibts auch für Windows), ansonsten gibts auch schon eine komplett von Bonjour unabhängige aber komplett dazu kompatible Implementierung im RemObjects SDK (falls man da eine Lizenz zur Hand hat).

Ansonsten hat's bei Torry noch ne Komponente um ein OpenSource SLP-Library anzusprechen: http://www.torry.net/authorsmore.php?id=4244

Hier ist die eindeutige Devise, sich auf die Schultern von Riesen zu stellen und das zu verwenden was es schon gibt, und nicht schon bei der Konzeption vorneweg ein neues eckiges Rad hinzustellen.

[Furtbichler]

Zitat:

Zitat von Phoenix (Beitrag 1209879)

Hier ist die eindeutige Devise, sich auf die Schultern von Riesen zu stellen und das zu verwenden was es schon gibt, und nicht schon bei der Konzeption vorneweg ein neues eckiges Rad hinzustellen.

Außer, wann will dazu lernen. Dann würde ich erst selbst basteln, bis es anfängt, weh zu tun und dann die ausgereifte Lösung verwenden.

Im professionellen Umfeld hast Du natürlich 100% Recht: Keine selbstgebastelten Frickellösungen.

[QuickAndDirty]

Zitat:

Zitat von Phoenix (Beitrag 1209879)

Ich finds ja immer wieder erstaunlich, wie oft so ein olles Rad neu erfunden werden soll.

Das ganze Broadcast-Zeug ist zwar prinzipiell sehr einfach, aber der Teufel steckt im Detail (Wahl der Intervalle, die Frage wer pollt und wer antwortet etc., was passiert wenn zwei Clients gleichzeitig im Netz aufploppen - wer aktiviert den Server?).

Die ganze Thematik Service Discovery / ZeroConf (Zero Configuration Networking) ist aber schon in aller Erschöpfung vollumfänglich mehrfach abgenudelt.

Die Grundlegenden Protokolle sind dabei DNS-DS (Apple's Bonjour bzw. ZeroConf) bzw. SLP.
Apple liefert für Bonjour ein SDK mit, so dass man das direkt verwenden kann (gibts auch für Windows), ansonsten gibts auch schon eine komplett von Bonjour unabhängige aber komplett dazu kompatible Implementierung im RemObjects SDK (falls man da eine Lizenz zur Hand hat).

Ansonsten hat's bei Torry noch ne Komponente um ein OpenSource SLP-Library anzusprechen: http://www.torry.net/authorsmore.php?id=4244

Hier ist die eindeutige Devise, sich auf die Schultern von Riesen zu stellen und das zu verwenden was es schon gibt, und nicht schon bei der Konzeption vorneweg ein neues eckiges Rad hinzustellen.

Ich habe eine Client Server Anwendung. Damit die (ziemlich fetten)Clients Funktionieren müssen sie eine Datenbankverbindung (Server, Port, Datenbank, Anmeldeart, User, Passwort) und einen UNC Pfad kennen.
Server Umzüge und Installationen sollen an Client-Rechnern möglichst keine Konfiguration nach sich ziehen. Es sind alles reine Delphi Anwendungen.
Was wäre da besser Bonjour/Zeroconf oder OpenSlp oder UPnP?

[Bernhard Geyer]

Zitat:

Zitat von QuickAndDirty (Beitrag 1222128)

Ich habe eine Client Server Anwendung. Damit die (ziemlich fetten)Clients Funktionieren müssen sie eine Datenbankverbindung (Server, Port, Datenbank, Anmeldeart, User, Passwort) und einen UNC Pfad kennen.
Server Umzüge und Installationen sollen an Client-Rechnern möglichst keine Konfiguration nach sich ziehen. Es sind alles reine Delphi Anwendungen.
Was wäre da besser Bonjour/Zeroconf oder OpenSlp oder UPnP?

Wenn die Client nicht schmalspurig angebunden sind: Was spricht dagegen die Exe's vom Fileserver zu starten? Dort hast du eine Config-Datei die geändert wird.
Ansonsten biete Windows genügend Mittel Änderungen an einer Configdatei automatisch (wie auch ganze installationen) zu verteilen.

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1222130)

Was spricht dagegen die Exe's vom Fileserver zu starten?

Updates. ;-)

[QuickAndDirty]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1222130)

Wenn die Client nicht schmalspurig angebunden sind: Was spricht dagegen die Exe's vom Fileserver zu starten? Dort hast du eine Config-Datei die geändert wird.

Nichts, außer das wir auf lange Sicht die Freigabe los werden wollen, um irgendwann mal ne windowskonforme Installation hinzubekommen. Wir unterstützen das Starten direkt aus der Freigabe heraus bereits über einen Mechanismus den wir auch im Terminalserverbetrieb einsetzen. Das geht wunderbar. Aber das einrichten einer Verknüpfung auf dem Client auf Desktop und Startmenü setzt leider dennoch die Kenntnis des UNC-Pfades beim Benutzer voraus. UPnP, OpenSLP oder ZeroConf könnten das, wenn z.b. ein "Einstellungsserver" verwendet wird, automatisch einrichten. Allerdings hilft das Starten per Verknüpfung vom Fileserver auch nicht, wenn eben dieser FileServer umzieht... :( Verpnüpfungen passen sich ja nicht automatisch an.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1222130)

Ansonsten biete Windows genügend Mittel Änderungen an einer Configdatei automatisch (wie auch ganze installationen) zu verteilen.

Das geht ohne Änderungen direkt am ClientPC durchzuführen?
Wäre natürlich cool, wenn man beim Setup am Server, einfach die Namen der ClientPCs angibt und dann alles automatisch auf den Clients eingerichtet wird. Besonders bei Serverumzügen würde mir das gefallen.
Wonach muss ich da suchen?