Entwickler-Ecke :: Thema anzeigen - Server im LAN finden

Gausi - Sa 28.07.07 14:28
Titel: Server im LAN finden

Ich experimentier grade noch an was anderem rum. Und zwar möchte ich übers LAN Daten austauschen. Hab also eine Server-Anwendung mit nem IdTCPServer (ich verwende Indy10) und eine Client-Anwendung, wo ein passender IdTCPClient sitzt. Kommunikation funktioniert auch soweit.

Jetzt ist die Frage, wie der Client den Server finden kann (d.h. ohne die IP-Adresse des Servers vom User eingeben zu lassen). Und da finde ich meine Lösung nicht so ganz gut. Ich sende vom Client über einen IdUDPClient einen Broadcast, den auf der Serveranwendung ein IdUDPServer empfängt.
Um dem Clienten das mitzuteilen, benutzt der Server nun einen weiteren IdUDP-Clienten, der die eigene IP an die IP sendet, von der der Broadcast kam. Auf dem Clienten empfängt das dann ein zweiter IdUDPServer.

Ich habe also

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

Client                             Server
-----------------------------------------------
                 Broadcast   
UDP-Client   ------------------>  UDP-Server
                                     |
              sendet Server-IP       |
UDP-Server   <------------------  UDP-Client
   |
   | IP speichern 
   |
   |          Anfragen/Antworten
TCP-Client  <--------------------> TCP-Server

Geht das auch einfacher?

Chryzler - Sa 28.07.07 14:38

Der Server könnte regelmäßig Broadcasts mit seiner IP verschicken, dann muss der Client nichts anderes als auf einen Broadcast warten. Das wäre die einzige Möglichkeit, denk ich.

Fighter#1 - Sa 28.07.07 17:18

Also gelöst habe ich das auch so, dass der Server alle 3 Sekunden einen Broadcast mit der IP losschickt!
Das funktioniert wunderbar! :-)

Gausi - Sa 28.07.07 17:25

Dass das funktioniert ist klar, die Idee hatte ich auch zwischendurch, aber müllt man damit nicht das LAN unnötig zu? Natürlich ist der Traffic nicht wirklich groß, aber doch irgendwie unnötig, oder?

(Und funktionieren tut meins auch ;-))

Fighter#1 - Sa 28.07.07 17:59

musst halt wissen was dir wichtiger ist xD
entweder haste unnötigen Traffic oder etwas mehr im Quelltext stehn!
Wobei, Narses TUDPSockUtil kannste auch verwenden! sind glaubich nicht so serverbasierend! Also du nimmst eine Komponente, die dann quasi Server und Client ist!

UGrohne - Sa 28.07.07 18:06

Der Traffic macht da nicht wirklich was aus. Geh mal ein normales Netzwerk mit nem Sniffer rein, was da so alles an Broadcasts rumschwirrt ;) Daher würde ich das wohl auch so umsetzen.

arj - Sa 28.07.07 18:09

Naja, der Client könnte allerdings doch bei einem Verbindungsversuch über TCP einen Broadcast absenden.
Mit entsprechendem Inhalt natürlich. Dann antwortet der Server dem Client und der Client weiß die Adresse.

Weitere Infos siehe http://de.wikipedia.org/wiki/Broadcast

Gausi - Sa 28.07.07 19:15

Nagut, überzeugt. Dann macht einfach der Server den Broadcast. :D

Aber wenn mein Bruder wieder meckert, dass der Router rauscht, dann seid ihr schuld. :mrgreen:

Chryzler - Sa 28.07.07 19:24

Du musst ja nicht alle 50ms einen Broadcast senden, imho reichen 5-8 Sekunden.

BenBE - Sa 28.07.07 19:48

Ansonsten implementier einfach Dual-Use:
1. In der Server-Anwendung wird in etwas größeren Intervallen (von caa. 15-30 Sekunden) ein Broadcast verschickt, der mitteilt "Ich bin ein Server, redet mit mir!"
2. Der Client darf explizit einen Broadcast senden (wenn er nicht dieses Interval abwarten will) mit dem Inhalt "liebe Server, ich suche euch".

So ähnlich läuft das nämlich bei UPnP ab: Wenn ein UPnP-Fähiges Gerät in einem Netzwerk ist, teilt dieses (in mehr oder weniger regelmäßigen Abständen) dem Netzwerk mit, hier bin ich. Ein Nutzer dieser Dienste kann aber auch explizit fragen "gibt es hier ein Gerät, was Dienst XY anbietet???".