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.