Server mit WinSock: Netzwerkbroadcast senden

[Dörti.Hermi]

Hallo Leute,

folgendes Problem: Ich habe einen WinSock-Server (mit TCP). Dieser soll sagen wir mal alle 5 Sekunden einen Broadcast senden, der den Sinn hat, das jeder Client, der diesen bestimmten Server sucht, den Server einfach finden kann.

Ich hab mir das ungefähr so vorgstellt: Der Server sendet an die Broadcastadresse (wenn ich das richtig verstaden habe, geht diese Nachricht dann an alle Clients im Subnet) einen bestimmten Zeichensatz, der ihn eindeutig identifiziert. Will sich nun ein Client mit dem Server verbinden, braucht er nur eine Such-Taste zu drücken. Dies hat zur Folge, dass der Client die Broadcastnachrichten vom Server erkennt und sich so dann mit dem Server verbindet. Ich will mir so ersparen, dass der Client die IP des Servers kennen muss...

Ich hoffe, ich hab's verständlich erklärt...

Mfg Andi

 

[Wessy]

Schon erledigt?

Wenn nicht: Schwieriges Thema. Eine Quick'n Dirty-Lösung wäre folgende:

Per Shell einen ICMP-Broadcast an die Broadcastadresse (z.B. PING 192.168.0.255) senden. Danach die Arp-Liste mit (ARP -A) auslesen und alle Netzwerkgeräte (können auch Router, Drucker, etc... sein) um eine Verbindung anhauen. Problem: Einfach Dirty da alle Netzwerk'geräte' in der ARP Liste stehen bzw. durch Netzwerksegmente etwas entferntere Geräte nicht auftauchen. Diese tauchen dann in ARP Listen von, Routern oder Switchen (?) anderer Segmente auf.

PS.: ICMP (also ping und tracert und so weiter) wird glaub ich eh nicht über Segmente hinweg weitergegeben.

Hoffe das war jetzt technisch gesehen alles 100%ig richtig. Auf jeden Fall Broadcast und anschließendes Auslesen der ARP Liste ist mit Boardmitteln möglich.

An deiner Stelle würd ich aber für ApplicationDiscoverys UDP verwenden. Bietet den Vorteil dass du keine expl. Verbindung benötigst um Daten zu senden. Die Remote-Adresse für das UDP-Socket kannst du einfach mal eben so ändern was bei TCP-Socket nicht möglich ist. Sollte so auch möglich sein alle möglichen IP-Adressen kurz mal mit einem Paket anzusprechen ohne groß zu warten. Noch eine Möglichkeit: Alle Clients updaten sich gegenseitig. Also jeder Client der keine oder eine Neue Serveradresse bekommt fragt/gibt diese per UDP an alle anderen Rechner im Netzwerk. So aktualisieren sich alle Clients gegenseitig. Ob das jedoch die Netzwerkadministratoren freut ist eine andere Geschicht.
*duck und weg*

 

[Wessy]

Ach was mir grad in den Kopf kommt:

Eigentlich total blöd und vermutlich schreien jetzt irgendwelche Netz-Admins laut auf, aber versuch doch mal das UDP-Socket an die Broadcastadresse zu binden. Also sendest einfach nen Packet an 192.168.0.255. Würd mich mal interessieren ob Clients das Ding dann bekommen. Nach meinem Netz-Grundwissen sollte das Paket aber an irgendeinen gehen.

 

[Wessy]

So jetzt komm ich auch wieder auf die Seite....

Ich hab das grad mal getestet. Scheinbar (habe nicht im LAN getestet) kommen auch UDP-Pakete an Broadcast-Adressen an. Werds zuhause im LAN verifizieren...

Hab das nur eben in nem Broadcast-Chat getestet.

 

[Dörti.Hermi]

Hi Wessy,

das mit dem UDP Broadcast hab ich mir auch schon gedacht. Habs leider noch nicht ausprobieren können. Die Frage ist nur, ob ich den Server eine Broadcast schicken lasse oder den Client. Wahrscheinlich ist es mit dem Client besser, weil es das Netzwerk nicht so belastet. Nur mir ist nicht ganz klar, wie ich dann auswerten soll, wer der Server ist.
Angenommen ich schicke per Client ein Paket mit dem Inhalt "searching" an die Broadcast-Adresse. Soll der Server dann bei jedem empfangenen Paket prüfen, ob der Inhalt des Pakets "searching" ist, und dann an diesen Client seine IP zurücksenden?

Lg Andi

 

[Wessy]

Also ob der Server oder der Client sendet liegt an deinen Anforderungen. Wenn z.B. dein Client direkt nach dem Start (z.B. Anmeldung des Benutzers) automatisch einen Server suchen soll, könntest du z.B. ein Paket mit dem Inhalt [SERVER-DISCOVERY] an 255.255.255.255 senden. Der Server empfängt dies und prüft (ja jedes Paket) ob der Inhalt [SERVER-DISCOVERY] ist und anwortet (natürlich nur direkt an die Client) mit [SERVER-IDENTIFICATION]...... ServerName, IP, Version, etc... Daraufhin empfängt der Client dies und prüft (auch jedes Paket) ob im so genannten Header [SERVER-IDENTIFICATION] steht und ließt die restlichen Daten wie ServerName, IP, Version, etc aus + anschließenden Verbindungsaufbau per TCP.

Anders: Wenn z.B. der Server alle Clients anstoßen will damit ein Update von einer Netzwerkfreigabe gezogen wird, so sollte der Broadcast von dem Server aus gesendet werden.


PS.: In jedem Fall solltest du, wenn es irgendwie möglich ist, die Broadcasts vom Server aus senden lassen. Denn stell dir vor: 1x Server + 50x Clients, bedeutet...

...bei einem Broadcast pro Minute...
vom einen Server aus = 1440 Pakete am Tag an alle Rechner im Netz
von allen Clients aus = 72000 Pakete am Tag an alle Rechner im Netz

PS.: Hatte letztens ein Broadcast-Chat-Programm geschrieben. Egal welcher Benutzer im Netzwerk (oder Internet) das Programm startet, kann direkt am Chat teilnehmen. Identifiziert werden die Benutzer dann über ihren Benutzernamen... Netzwerktechnisch nicht der Hit, aber einfach zu bedienen!