Wie findet der Client seinen Server?

[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 von BUG:

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 von 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?

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 von jfheins:

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 von Phoenix:

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 von 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.

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 von QuickAndDirty:

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.