UDP Verständnisfrage

[ByTheTime]

Moin,
also in Sachen Netzwerk bin ich eigentlich kein Neuling, allerdings habe ich in den letzen Monaten nicht viel mit Netzwerkprogrammierung am Hut gehabt, und jetzt steh ich auf dem Schlauch (Und mit UDP hatte ich noch nie was am Hut ).

Folgende Situation: Ein Rechner wird an ein Netzwerkkabel angeschlossen und soll einem Server dann selbstständig seine lokale IP-Adresse mitteilen. Dafür wäre ja UDP perfekt. Jetzt soll das aber nur nach Aufforderung passieren. Das Prinzip sieht so aus:

Server ---Broadcast---> "Hallo, sind blinde Rechner im Netzwerk?" ---> Rechner: "Jo, 192.168.xxx.xx" ---> Server

UDP und die Indys würden sich dafür perfekt eignen. Jetzt aber eine kleine Frage:
Auf dem Server soll der UDPClient laufen, welcher zu bestimmten Zeitpunkten einen Anfrage via Broadcast durchführt. Der wird vom UDPServer auf dem "blinden" Rechner aufgegriffen und der soll nun seine IP mitteilen. Muss ich die dann ebenfalls zurück broadcasten, oder enthält der Broadcast die "Zielkoordinaten" des Absenders, so das ich direkt eine Verbindung aufbauen kann?

Gruß,
Lukas

[Uwe Raabe]

Der empfangende Teil kann die Sender-IP im OnUDPRead aus dem ABinding -Parameter ermitteln. Das entsprechende Property heißt PeerIP .

[Sir Rufo]

Der Server verschickt per UDP in regelmäßigen Abständen unter welcher Adresse (IP und Port) er zu erreichen ist.

Die Clients verbinden sich dann einfach mit dem Server, wenn diese Nachricht empfangen wurde, denn nun wissen diese, wo der Server auf sie wartet

http://www.delphipraxis.net/174102-w...en-server.html

[ByTheTime]

Oh... Ich wusste doch das ich etwas durcheinander geworfen habe Die Client-Server-Struktur Das wäre doch etwas sinnvoller

Und danke Uwe für den Tipp, die EIgenschaft habe ich ganz übersehen Genau das was ich gesucht habe.

Also doch garnicht so schwer Danke das ihr mir auf die Sprünge geholfen habt

[Medium]

Ich bevorzuge da den entgegen gesetzen Weg: Client wird gestartet, und fragt per Broadcast "Ist hier irgendwo mein Server?" Der Server erkennt am Payload dass er gemeint ist, und schickt dem Client direkt eine Antwort "Jup, ich bin dein Kandidat." Dann wird die TCP Verbindung aufgebaut, und los gehts.
Ich finde das deswegen eleganter, weil meistens ja doch seltener neue Clients kommen, als ein Server dann seinen Broadcast im Netz "spammen" müsste.

[mjustin]

Zitat von Medium:

Ich bevorzuge da den entgegen gesetzen Weg: Client wird gestartet, und fragt per Broadcast "Ist hier irgendwo mein Server?" Der Server erkennt am Payload dass er gemeint ist, und schickt dem Client direkt eine Antwort "Jup, ich bin dein Kandidat." Dann wird die TCP Verbindung aufgebaut, und los gehts.
Ich finde das deswegen eleganter, weil meistens ja doch seltener neue Clients kommen, als ein Server dann seinen Broadcast im Netz "spammen" müsste.

Andererseits ist es bei einer von den Clients ausgelösten Serversuche leichter, den Server mit einem DDOS Angriff - viele, eventuell auch manipulierte UDP Pakte - zu überlasten.
Ein Server dagegen, der nur UDP versendet, aber nie UDP Pakete empfangen braucht, kann durch die Firewall leicht vor Angriffen geschützt werden.
Links zum Thema:

1. http://en.wikipedia.org/wiki/UDP_flood_attack
2. http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon

[BUG]

Zitat von mjustin:

Andererseits ist es bei einer von den Clients ausgelösten Serversuche leichter, den Server mit einem DDOS Angriff - viele, eventuell auch manipulierte UDP Pakte - zu überlasten.

Das Argument kommt mir komisch vor. UDP-Broadcast ist (egal in welche Richtung) im Internet afaik nicht möglich.
Wenn dein Angreifer im eigenen Netz sitzt ... dann hast du vermutlich andere Probleme als DDoS.

Ein verwandtes Problem sehe ich in dem Moment, wo der Server (z.B. nach einen Reboot) wieder online geht und sofort mit Anfrage von allen Clients im Netz bombardiert wird, die natürlich jetzt den Server suchen.

[Medium]

Ein DDoS im LAN? Würde ich auch in die Kategorie "größere, andere Probleme" stecken. Zur Not gibt es auch Switches/Router die solche Aktionen heuristisch zu erkennen und unterbinden vermögen. Ein "Spike" nach einem Reboot ist jedoch ein Argument. Bisher kamen bei mir selten >20 Clients vor, wenn überhaupt, und die fangen auch nicht alle wild mit Broadcasts an, da der Server bei uns immer eine feste IP hat*. Sie versuchen daher lediglich in Intervallen ein TCP Reconnect, welchen man auch hat wenn der Server seine Adresse heraus posaunt. Noch ein Vorteil vom broadcastenden Client: Wenn ich nicht 100%ig weiss wie der Client fragt, findet so schnell keiner den Server, der es nicht soll. (Klar, sicher ist das alleine nicht. Aber jede kleine Hürde kann helfen.)
Am Ende ist es wie fast immer Abwägungssache und von den individuellen Anforderungen ans System abhängig.

*) Die dynamische Serversuche ist bei uns eher ein Feature für uns, wenn wir neue Clients ins Netz nehmen, oder schnell ein PC vom Kunden einen defekten von uns temporär ersetzen soll. Spart die Config, und einfaches Programm kopieren ist alles was nötig ist. (Sowas in der Art z.B. meinte ich mit individuellen Anforderungen )