[idUDPClient] Broadcast auf allen Interfaces raus senden

[Assertor]

Hi Alex,

Zitat von gsh:

Zitat von Assertor:

Mag sein, bin gerade am Arbeiten

Ich auch

Zitat von gsh:

Zitat von Assertor:

Als Problem sehe ich auch, daß Ethernet-Broadcast mit der Zieladresse 255.255.255.255 von Routern nicht weitergeleitet werden. Dann müßte man in Richtung Multicast gehen.

Das wäre nicht schlimm ... Aber dies könnte man auf einem "guten" Router auch weiterleiten.

Richtig, wobei man die Admins, die das machen mal über Netzwerk-Sicherheit informieren sollte - zumindest wenn über Netzwerkzonen hinweg der FF Multicast geroutet wird.

Zitat von gsh:

Ok ich versuche es noch mal genau zu erklären:

Ich möchte das sich mein Programm selber im Netzwerk finden kann. In den meisten Fällen wird es wahrscheinlich in einer einfachen Netzwerk umgebung sein (Privates Netzwerk) wo alle Computer im gleichen Subnetz sind. Bei Firmen die das dann auch über größere Netzwerke legen wollen müssen halt die Router so konfigurieren das die diese Broadcasts durchlassen (Dies ist aber nicht mein Problem).
Zurzeit habe ich das Problem so gelöst:
Sobald mein Programm startet (und danach alle 5 min) sendet es einen UDP Broadcast an 255.255.255.255. Wenn auf einem anderen PC dieses Packet empfangen wird dann sendet dieser PC einen Unicast an den ersten PC. Danach wissen beide von einander und können dann später mit einander komunizieren. Die IP Adresse von dem Gegenüber PC erhalten sie im Moment eben über die Source-IP.
Das Konzept funktioniert auch super solange nur 1 Interface auf jedem Computer existiert. Sobald aber mehrere Interfaces und somit mehere Source IP Adressen vorhanden sind gibt es eben die oben beschriebenen Probleme.

Ich hoffe du weißt jetzt was ich erreichen will.
Noch mal danke das du mir hilfst

Keine Ursache, ist ja auch ein interessantes Thema.

Die Erklärung macht jetzt einiges klar. Also prinzipiell bleiben zwei Möglichkeiten: Broadcast über alle lokalen Adapter (wie oben gesagt muß Du da leider selbst durch iterieren) oder aber eine manuelle Bindung.

Ich würde jetzt den Weg des geringsten Wiederstands gehen: Für den Fall, daß mehrere Adapter vorhanden sind, wird Deine Anwendung oder Anwendungsinstanz an einen Adapter gebunden (z.B. per IP-Eingabe). So muß man es bei anderen Netzwerk-Tools auch häufig machen.

Wenn ich mir jetzt z.B. die UDP-Multicast-Pakete meines Netzwerkdrucks ansehe, sendet dieser auch im Multicast seine eigene IP nochmals mit. Wahrscheinlich auch um dieses Problem einfach zu umgehen.

Oder Du schreibst in die Dokumentation, daß bei mehreren Adaptern im System die Priorität über die Source-IP entscheidet, daher diese auch von den Clients per Route erreichbar sein muß.

Als Admin würde ich sowieso die betreffenden IPs der anderen Zielrechner im DNS hinterlegen, damit die Clients des anderen Subnetz immer wissen, wo sie diese über den Multiforwarder des Server erreichen können. Früher hat man das ja über die lmhosts etc gelöst.

Aber eine schönere Lösung fürs Programmieren sehe ich nicht. Ein Broadcast mit automatisch wechselnden Quell-IPs pro Adapter gibt es meines Wissens nach nicht.

Gruß Assertor

[gsh]

Zitat von Assertor:

Keine Ursache, ist ja auch ein interessantes Thema.

Die Erklärung macht jetzt einiges klar. Also prinzipiell bleiben zwei Möglichkeiten: Broadcast über alle lokalen Adapter (wie oben gesagt muß Du da leider selbst durch iterieren) oder aber eine manuelle Bindung.

Ich würde jetzt den Weg des geringsten Wiederstands gehen: Für den Fall, daß mehrere Adapter vorhanden sind, wird Deine Anwendung oder Anwendungsinstanz an einen Adapter gebunden (z.B. per IP-Eingabe). So muß man es bei anderen Netzwerk-Tools auch häufig machen.

Wenn ich mir jetzt z.B. die UDP-Multicast-Pakete meines Netzwerkdrucks ansehe, sendet dieser auch im Multicast seine eigene IP nochmals mit. Wahrscheinlich auch um dieses Problem einfach zu umgehen.

Oder Du schreibst in die Dokumentation, daß bei mehreren Adaptern im System die Priorität über die Source-IP entscheidet, daher diese auch von den Clients per Route erreichbar sein muß.

Als Admin würde ich sowieso die betreffenden IPs der anderen Zielrechner im DNS hinterlegen, damit die Clients des anderen Subnetz immer wissen, wo sie diese über den Multiforwarder des Server erreichen können. Früher hat man das ja über die lmhosts etc gelöst.

Aber eine schönere Lösung fürs Programmieren sehe ich nicht. Ein Broadcast mit automatisch wechselnden Quell-IPs pro Adapter gibt es meines Wissens nach nicht.

Als erstes will ich mich entschuldigen das ich erst jetzt zurück schreibe, ich hatte aber bis jetzt keine Zeit dafür.

Also eine manuelle Bindung auf einen Adapter möchte ich eigentlich verhindern da ich ja eigentlich will, dass es auf allen Adaptern ein richtiger Broadcast gesendet wird. Die IP im Broadcast mitschicken ist auch nicht gerade zielführend da ich nicht genau was welche die richtige IP ist unter der mich dann alle Clients erreichen können.

Ich habe mir noch eine andere Möglichkeit überlegt. Diese ist zwar nicht einfach aber für den User die beste Möglichkeit:
Das Programm schaut beim Start nach welche Adapter und welche IP Adressen konfiguriert sind. Dann überlegt es sich anhand der IP und Subnet Maske wie der Broadcast aussehen muss. Bindet dann auf dem ersten Adapter und sendet dann einen beschränkten Broadcast raus und das bei allen Adaptern.

Bsp:

Ein Lan 1 (192.168.1.100, 255.255.255.0) und Lan 2 (10.0.1.100, 255.255.0.0):
Als erstes Lan 1: Broadcast muss an die 192.168.1.255. Bind Adresse: 192.168.1.100
Dann Lan 2: Broadcast muss an die 10.0.255.255. Bind Adresse: 10.0.1.100


Verbesserungsvorschläge bzw. Ideen wie ich das am besten in einen Algorithmus packen könnte nehme ich gerne an

[Assertor]

Hi,

noch eine Überlegung: Warum drehst Du das ganze nicht einfach um? Die Software auf den Clients sendet solange einen UDP Broadcast, bis der Server sich verbindet. Der Server braucht dann nicht mit einem Broadcast zu antworten, sondern kann sich direkt z.B. per TCP zum Client verbinden - ohne jemals einen eigenen Broadcast senden zu müssen.

Das schaut für mich irgendwie schöner und effektiver aus.

Zusätzlich:
- Das ganze natürlich mit Fehlerbehandlung bei C/S
- Einer Client-Liste, die Du auf der Serverseite verwaltest (mit automatischer Entfernung, wenn über Zeitraum x der Client nicht erreichbar war und limitiert auf y Einträge)
- Die Broadcasts in Intervallen (resourcenschonender), am Anfang z.B. alle 5 Sekunden, dann imme größere Abstände
- Damit der Benutzer nicht ewig warten muß noch ein Start Broadcast vom Server, damit die Clients Ihr Broadcast-Sendeintervall wieder auf 5 Sekunden setzen

Ich glaube, so würde ich das machen. Keine Konfiguration wegen der Multi-Interface-Geschichte.

Gruß Assertor

[gsh]

Zitat von Assertor:

Hi,

noch eine Überlegung: Warum drehst Du das ganze nicht einfach um? Die Software auf den Clients sendet solange einen UDP Broadcast, bis der Server sich verbindet. Der Server braucht dann nicht mit einem Broadcast zu antworten, sondern kann sich direkt z.B. per TCP zum Client verbinden - ohne jemals einen eigenen Broadcast senden zu müssen.

Das schaut für mich irgendwie schöner und effektiver aus.

Zusätzlich:
- Das ganze natürlich mit Fehlerbehandlung bei C/S
- Einer Client-Liste, die Du auf der Serverseite verwaltest (mit automatischer Entfernung, wenn über Zeitraum x der Client nicht erreichbar war und limitiert auf y Einträge)
- Die Broadcasts in Intervallen (resourcenschonender), am Anfang z.B. alle 5 Sekunden, dann imme größere Abstände
- Damit der Benutzer nicht ewig warten muß noch ein Start Broadcast vom Server, damit die Clients Ihr Broadcast-Sendeintervall wieder auf 5 Sekunden setzen

Ich glaube, so würde ich das machen. Keine Konfiguration wegen der Multi-Interface-Geschichte.

Gruß Assertor

Also entweder hast du jetzt einen Denkfehler oder ich hab dich nicht richtig verstanden.
Es gibt keinen wirklichen Server, alles ist dezentralisiert!

Aktuell läuft das ganze so ab:
Client1 startet und sendet somit einen Broadcast "Ich bin Client1, gibt es noch andere Clients?"
Client2 empfängt diesen und sendet direkt zu Client1 das Antwortpacket (UDP) "Ja mich gibt es auch, ich heiße Client2"

Genau bei dem Antwortpacket von Client2 ist jetzt das Problem. Auf welche IP soll er dieses nämlich hinschicken? Da er nur die Soure-IP von dem Client über den Broadcast kennt muss er das Packet auf diese senden.

(Solche zusätze das es in einem bestimmten Intervall den Boradcast sendet habe ich schon implementiert)

[Assertor]

Zitat von gsh:

Also entweder hast du jetzt einen Denkfehler oder ich hab dich nicht richtig verstanden.
Es gibt keinen wirklichen Server, alles ist dezentralisiert!

Ja, dann ist mein Ansatz natürlich verkehrt.

Zitat von gsh:

Aktuell läuft das ganze so ab:
Client1 startet und sendet somit einen Broadcast "Ich bin Client1, gibt es noch andere Clients?"
Client2 empfängt diesen und sendet direkt zu Client1 das Antwortpacket (UDP) "Ja mich gibt es auch, ich heiße Client2"

Genau bei dem Antwortpacket von Client2 ist jetzt das Problem. Auf welche IP soll er dieses nämlich hinschicken? Da er nur die Soure-IP von dem Client über den Broadcast kennt muss er das Packet auf diese senden.

Dann bleiben nur die o.g. Möglichkeiten. Wenn es, wie ich vermute, um eine P2P Lösung geht (über VPN), schau Dir doch mal die folgenden Seiten und Komponenten für Anregungen zur Lösung an:

http://www.aidaim.com/delphi_messeng...sdk_im_sdk.htm
http://www.delphisource.com/componen...198&category=6
http://eldos.com/msgconnect/
http://www.lionknight.com/filexfer/Features.aspx

Zitat von gsh:

(Solche zusätze das es in einem bestimmten Intervall den Boradcast sendet habe ich schon implementiert)

Gruß Assertor

[gsh]

Zitat von Assertor:

Dann bleiben nur die o.g. Möglichkeiten. Wenn es, wie ich vermute, um eine P2P Lösung geht (über VPN), schau Dir doch mal die folgenden Seiten und Komponenten für Anregungen zur Lösung an:

http://www.aidaim.com/delphi_messeng...sdk_im_sdk.htm
http://www.delphisource.com/componen...198&category=6
http://eldos.com/msgconnect/
http://www.lionknight.com/filexfer/Features.aspx

Also es soll zwar so eine Art P2P Lösung sein aber hat nicht wirklich was mit VPN zu tun. (Hab ich doch schon öfter gesagt das Hamachi nur ein Beispiel war).
Trotzdem danke für die Links.
Beim 2 Link ist der Download down.
Bei den anderen drei habe ich mir zwar angeschaut werde jedoch nicht ganz schlau daraus. Alle kann man kaufen und die Trail hilft mir auch nicht weiter.

Und nur noch mal zur Info. Ich hab nur ein Problem mit dem Broadcast nicht mit der P2P funktionalität.

[Assertor]

Zitat von gsh:

Also es soll zwar so eine Art P2P Lösung sein aber hat nicht wirklich was mit VPN zu tun. (Hab ich doch schon öfter gesagt das Hamachi nur ein Beispiel war).

Ja, mit dem VPN hatte ich gelesen, deswegen hab ich das in Klammern geschrieben.

Zitat von gsh:

Trotzdem danke für die Links.
Beim 2 Link ist der Download down.

Bitte, gern. Gut, den 2. Link dann einfach ignorieren.

Zitat von gsh:

Bei den anderen drei habe ich mir zwar angeschaut werde jedoch nicht ganz schlau daraus. Alle kann man kaufen und die Trail hilft mir auch nicht weiter.

Und nur noch mal zur Info. Ich hab nur ein Problem mit dem Broadcast nicht mit der P2P funktionalität.

Es geht auch nicht darum, die Komponenten zu nutzen. Laden, testen und gucken, wie die Hersteller es gelöst haben. Packet Sniffer anwerfen und prüfen, was für Broadcasts rausgehen (directed, limited) oder ob Multicast oder ARP-Broadcasts genutz werden. Das kannst du prinzipiell aber auch mit jeder anderen P2P Lösung machen (Sourcen von emule & co mal ansehen?).

Wenn Du dann eine gute Implementation gefunden hast, die für Deinen Bereich geht, baust Du es genauso auf.

Gruß Assertor

[gsh]

Zitat von Assertor:

Es geht auch nicht darum, die Komponenten zu nutzen. Laden, testen und gucken, wie die Hersteller es gelöst haben. Packet Sniffer anwerfen und prüfen, was für Broadcasts rausgehen (directed, limited) oder ob Multicast oder ARP-Broadcasts genutz werden. Das kannst du prinzipiell aber auch mit jeder anderen P2P Lösung machen (Sourcen von emule & co mal ansehen?).

Wenn Du dann eine gute Implementation gefunden hast, die für Deinen Bereich geht, baust Du es genauso auf.

ok also die Software die du mir geschickt hast hab ich nicht zum laufen bekommen. Aber ich werde ein paar andere P2P Programm analysieren.
Angefangen hab ich mal mit Trillian ... dieses hat ein Lan Plugin. Folgendes Packet hab ich mitdumpen können:

Code:

192.168.0.56   224.0.0.251   MDNS   Standard query PTR _presence._tcp.local, "QM" question AAAA nbalex.local, "QM" question

Auf jeden Adapter sendet er mit der richtigen Source-IP. Warum kann das bei UDP nicht auch so einfach sein?

Mal eine blöde Frage kann das ein Fehler der Winsocks sein das der UDP Broadcast so Problematisch gesendet wird oder hat es irgendeinen guten Grund warum er mit der "falschen" Source-IP sendet?

[Assertor]

Zitat von gsh:

Aber ich werde ein paar andere P2P Programm analysieren.
Angefangen hab ich mal mit Trillian ... dieses hat ein Lan Plugin. Folgendes Packet hab ich mitdumpen können:

Code:

192.168.0.56   224.0.0.251   MDNS   Standard query PTR _presence._tcp.local, "QM" question AAAA nbalex.local, "QM" question

Auf jeden Adapter sendet er mit der richtigen Source-IP. Warum kann das bei UDP nicht auch so einfach sein?

Mal eine blöde Frage kann das ein Fehler der Winsocks sein das der UDP Broadcast so Problematisch gesendet wird oder hat es irgendeinen guten Grund warum er mit der "falschen" Source-IP sendet?

Er sendet nicht mit der falschen IP. Der Broadcast ist vollkommen richtig. Es wird die Priorität der Adapter vom System berücksichtigt (1. Seite hier mit den Routen). Das sollte und muß bei jedem anderen System auch so sein - unabhängig vom Betriebssystem.

Trillian sendet keinen Broadcast, sondern einen mDNS (Multicast DNS). Apple Bonjour macht das gleiche und viele andere (MS) auch. Lies Dir mal http://files.multicastdns.org/draft-...lticastdns.txt durch. Insbesondere was die Gruppe, den TTL und die Probleme mit miskonfigurierten Hosts (Dein nicht-routender-mehrfach-IP-PC) etc. angeht. Auch in Bezug auf Abschnitt 15. "Considerations for Multiple Interfaces" steht da einiges zu der Problematik. Gerade was Laptops mit LAN und WLAN-Schnittstellen angeht. Diese könnten u.U. überbrückt sein und würde Millisekunden später auf dem anderen Adapter als UDP/mDNS Multicast auftauchen.

Für solche Multicasts gibt es in Indy den IPMCastServer und Client. Ich würde mal probieren, darüber etwas zu erreichen. Bei IPMCastServer mußt Du aber wieder die Bound-IP für den Ausgangsadapter festlegen (sonst vom System automatisch).

Aber ein fertige, kostenlose Komponente die das alles für Dich erledigt kenne ich nicht. Wie meine Links oben Zeigen, läßt sich hiermit gutes Geld verdienen und es verschenkt niemand.

Ich empfehle wirklich mal in die Sourcen von irgendwelchen P2P Implementationen zu sehen und die Logik für die mDNS/Broadcasts-Konnektivität entsprechend zu adaptieren. Dafür muß man ja kein C++ Guru sein

Gruß Assertor

[gsh]

Zitat von Assertor:

Er sendet nicht mit der falschen IP. Der Broadcast ist vollkommen richtig. Es wird die Priorität der Adapter vom System berücksichtigt (1. Seite hier mit den Routen). Das sollte und muß bei jedem anderen System auch so sein - unabhängig vom Betriebssystem.

Trillian sendet keinen Broadcast, sondern einen mDNS (Multicast DNS). Apple Bonjour macht das gleiche und viele andere (MS) auch. Lies Dir mal http://files.multicastdns.org/draft-...lticastdns.txt durch. Insbesondere was die Gruppe, den TTL und die Probleme mit miskonfigurierten Hosts (Dein nicht-routender-mehrfach-IP-PC) etc. angeht. Auch in Bezug auf Abschnitt 15. "Considerations for Multiple Interfaces" steht da einiges zu der Problematik. Gerade was Laptops mit LAN und WLAN-Schnittstellen angeht. Diese könnten u.U. überbrückt sein und würde Millisekunden später auf dem anderen Adapter als UDP/mDNS Multicast auftauchen.

Für solche Multicasts gibt es in Indy den IPMCastServer und Client. Ich würde mal probieren, darüber etwas zu erreichen. Bei IPMCastServer mußt Du aber wieder die Bound-IP für den Ausgangsadapter festlegen (sonst vom System automatisch).

Aber ein fertige, kostenlose Komponente die das alles für Dich erledigt kenne ich nicht. Wie meine Links oben Zeigen, läßt sich hiermit gutes Geld verdienen und es verschenkt niemand.

Ich empfehle wirklich mal in die Sourcen von irgendwelchen P2P Implementationen zu sehen und die Logik für die mDNS/Broadcasts-Konnektivität entsprechend zu adaptieren. Dafür muß man ja kein C++ Guru sein

Gruß Assertor

Ok danke ich schaus mir mal an.