[idUDPClient] Broadcast auf allen Interfaces raus senden

[gsh]

Hi Leute

Ich habe das Problem das meine idUDPClient Komponente nur den Broadcast nur auf einem Interface rausschickt. Dieser Broadcast ist zum finden von anderen Clienten im Netz. Wenn ich jetzt aber z.b. Hamachi installiert habe sendet er den Broadcast mit der 5.x.x.x Adresse weg. Wenn das Hamachi dabei aber nicht läuft dann geht das Packet verloren.

Wie kann ich jetzt dem idUDPClient beibringen das er auf alle interfaces die er findet einen Broadcast raus sendet?

Mein Code zum senden:

Delphi-Quellcode:

IdUDPClient.BroadcastEnabled := true;
IdUDPClient.Broadcast('Hallo', vUDPPort);

Mein idUDPServer wird so gestartet:

Delphi-Quellcode:

IdUDPServer.DefaultPort := vUDPPort;
IdUDPServer.OnUDPRead := UDPServerUDPRead;
IdUDPServer.OnUDPException := UDPServerOnException;
IdUDPServer.Bindings.Add.IP := '0.0.0.0';
IdUDPServer.Active := true;

[gsh]

*push*
:duck:

[gsh]

:duck:

[gsh]

:duck:

[x000x]

Moin moin,

kenne Hamachi nicht... scheint aber auch nix mit deinem Problem zu tun zu haben.

Normalerweise sendest du einen Broadcast auf z.B. 192.168.1.255 oder 192.168.255.255 u.s.w. halt
je nachdem welches Netz du erreichen willst. Das sollte bei Indy ungefähr so aussehen

Delphi-Quellcode:

//...
   IdUDPClient.Host := '255.255.255.255';
   IdUDPClient.BroadcastEnabled:= True;
   IdUDPClient.Broadcast ('HALLO', vUDPPort);
//...

Damit sollte der broadcast über alle interfaces rausgehen (Vorraussetzung ist natürlich ein konfiguriertes Netzwerk)
Hierbei entscheidet aber letztendlich das Routing welche Schnittstellen benutzt werden.
Eingabeaufforderung:

Code:

c:\> route print

zeigt dir die Schittstellen an die benutzt werden.

[gsh]

Zitat:

Zitat von x000x

Damit sollte der broadcast über alle interfaces rausgehen (Vorraussetzung ist natürlich ein konfiguriertes Netzwerk)

JA der Boradcast SOLLTE über alle interfaces rausgehen ... tut er aber nicht <--- und genau das ist das Problem

Zitat:

Zitat von x000x

Hierbei entscheidet aber letztendlich das Routing welche Schnittstellen benutzt werden.
Eingabeaufforderung:

Code:

c:\> route print

zeigt dir die Schittstellen an die benutzt werden.

nicht unbedingt
Mein Routingtable:

Code:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1   192.168.0.100       10
          5.0.0.0        255.0.0.0     5.209.227.44    5.209.227.44       20
     5.209.227.44  255.255.255.255        127.0.0.1       127.0.0.1       20
    5.255.255.255  255.255.255.255     5.209.227.44    5.209.227.44       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0    192.168.0.100   192.168.0.100       10
    192.168.0.100  255.255.255.255        127.0.0.1       127.0.0.1       10
    192.168.0.255  255.255.255.255    192.168.0.100   192.168.0.100       10
        224.0.0.0        240.0.0.0     5.209.227.44    5.209.227.44       20
        224.0.0.0        240.0.0.0    192.168.0.100   192.168.0.100       10
  255.255.255.255  255.255.255.255     5.209.227.44    5.209.227.44       1
  255.255.255.255  255.255.255.255    192.168.0.100   192.168.0.100       1
Standardgateway:       192.168.0.1

So das Standartgateway ist also mein router ... also mein LAN
Der Broadcast geht aber über die Hamachi schnittstelle weil hamachi in der adapter reihenfolge ganz oben ist

[x000x]

Moin moin,

für das Routing sind eigentlich die Ziele insteressant. Wenn du in deinem Client den Host
255.255.255.255 her nimmst, dann wird in die Routingtabelle geschaut, über welche Schnittstelle
gesendet wird. In diesem und deinem Fall wären es:

Code:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Metrik
---------------------------------------------------------------------------
...
  255.255.255.255  255.255.255.255     5.209.227.44    5.209.227.44       1
  255.255.255.255  255.255.255.255    192.168.0.100   192.168.0.100       1

Da für die 255.255.255.255 eine (2) Route(n) vorhanden ist, ist das Standardgateway eigentlich uninteressant, sondern nur
diese beiden Zeilen. Wie hier jetzt aber entschieden wird, welches Interface genommen wird... da bin ich im Moment
auch überfragt, da ja auch die Metrik gleich ist... hm, evtl. kommt ja nochmal einer der Ahnung hat. Sorry...

[gsh]

Zitat:

Zitat von x000x

Da für die 255.255.255.255 eine (2) Route(n) vorhanden ist, ist das Standardgateway eigentlich uninteressant, sondern nur
diese beiden Zeilen. Wie hier jetzt aber entschieden wird, welches Interface genommen wird... da bin ich im Moment
auch überfragt, da ja auch die Metrik gleich ist... hm, evtl. kommt ja nochmal einer der Ahnung hat. Sorry...

ja ok wahrscheinlich nimmt er dann da einfach die erste

Eine Frage was ich mir stell: Ist das Absicht das er nur eine nimmt oder ein Fehler in den Indys (oder von Windows)?

[x000x]

Moin moin nochmal,

Zitat:

Zitat von gsh

Eine Frage was ich mir stell: Ist das Absicht das er nur eine nimmt oder ein Fehler in den Indys (oder von Windows)?

Ok, weder noch... Wenn du dir mal den Artikel durchliest, wirst du feststellen, dass ich auch etwas daneben lag.
Wenn du mit Client.Broadcast() einen Broadcast sendest, geht der immer als Ethernet-Broadcast an die MAC-Adresse FF:FF:FF:FF:FF:FF.

Zitat:

Zitat von Wikipedia

Limited Broadcast
Als Ziel wird die IP-Adresse 255.255.255.255 angegeben. Dieses Ziel liegt immer im eigenen Netz und wird direkt in einen Ethernet-Broadcast umgesetzt. Ein limited broadcast wird von einem Router nicht weitergeleitet.

Für dich ist dann wohl ein Directed Broadcast interessant.

Zitat:

Zitat von gsh

...Wenn ich jetzt aber z.b. Hamachi installiert habe sendet er den Broadcast mit der 5.x.x.x Adresse weg. Wenn das Hamachi dabei aber nicht läuft dann geht das Packet verloren...

Das versteh ich aber trotzdem noch nicht wirklich. Was passiert da nochmal genau?

[gsh]

Zitat:

Zitat von x000x

Für dich ist dann wohl ein Directed Broadcast interessant.

hmm das wird nicht so leicht. Den dann muss ich mir zuerst alle IPs holen richtig mit der Subnetmask das Netz raus filtern und dann einen directed Broadcast rausschicken ...

Zitat:

Zitat von x000x

Zitat:

Zitat von gsh

...Wenn ich jetzt aber z.b. Hamachi installiert habe sendet er den Broadcast mit der 5.x.x.x Adresse weg. Wenn das Hamachi dabei aber nicht läuft dann geht das Packet verloren...

Das versteh ich aber trotzdem noch nicht wirklich. Was passiert da nochmal genau?

Sobald du Hamachi installierst setzt er z.b. die 5.x.x.x route fest in das system ein. Wenn du also einen ping zu 5.1.1.1 machst dann geht er durch den routing table zum hamachi adapter. Da aber mein hamachi nicht immer läuft wird das packet dann einfach gedropt weil es nicht durch einen vpn tunnel weitergeleitet werden kann.
Somit geht dann auch mein broadcast verloren weil dieser nur über den hamachi adapter gesendet wird.

[gsh]

hat noch jemand eine idee dazu?

[gsh]

SRY leute muss mich entschuldigen bin gerade draufgekommen das der Broadcast auf allen Interfaces raus geht... ABER er geht immer mit der IP Adresse vom ersten Adapter weg.

Das Packet geht also über mein wirkliches interface mit der hamachi source IP raus. Das ist zum antworten auf der gegenseite natürlich gar nicht gut. Ist das ein konfigurationsfehler von mir oder ein Bug in den Indys?

[gsh]

ich hab mich jetzt mit den bindings ein bisschen rumgespielt aber ich schafe es einfach nicht das der broadcast vom normallen interface mit der richtigen source IP rausgeht :wall:

Hat das Indy Projekt einen Bug Tracker (hab nur einen premium support gefunden)?

[gsh]

:duck:

[Assertor]

Hi,

Konfigurationsfehler ;) Du mußt die IP festlegen, wenn Du die ausgehende IP nicht automatisch (vom System) bestimmt haben willst:

Delphi-Quellcode:

IdUDPClient1.BoundIP := '192.168.100.1'; // muß eine gültige IP sein
IdUDPClient1.Broadcast('Hello World by Indy', 12345);

Der Broadcast selbst wird natürlich auf allen Adaptern gesendet, da er an die 255.255.255.255 geht. Ein Broadcast halt. Gerade getestet, das geht einwandfrei. Also kein Grund, ein Indy Bug Report zu senden ;)

Gruß Assertor

[gsh]

Zitat:

Zitat von Assertor

Hi,

kein Grund für einen Bug-Report. Du mußt die IP festlegen, wenn Du die ausgehende IP nicht automatisch (nach System-Reihenfolge) bestimmt haben willst:

Delphi-Quellcode:

IdUDPClient1.BoundIP := '192.168.100.1'; // muß eine gültige IP sein
IdUDPClient1.Broadcast('Hello World by Indy', 12345);

Der Broadcast selbst wird natürlich auf allen Adaptern gesendet, da er an 255.255.255.255 geht. Ein Broadcast halt. Gerade getestet, das geht einwandfrei. Also kein Grund, ein Indy Bug Report zu senden ;)

Gruß Assertor

Danke für deine Antwort

das Problem ist das der Broadcast über den Adapter mit der jeweiligen Source-IP rausgehen muss.
Wenn ich jetzt wie du beschrieben hast die IP manuell setze dann geht der Broadcast auf allen Adapter mit der manuel festgelegten Source IP raus. Was aber wieder beim ersten Adapter schlecht ist.

Zum besseren Verständniss ein beispiel: (Packet geht mit folgender Source-IP raus)

So sieht es ohne manuelle IP aus

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 5.x.x.x

Wenn ich die IP manuel auf 192.168.0.x ändern

Hamachi-Adapter: 192.168.0.x
LAN-Adapter: 192.168.0.x

So sollte es aussehen

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 192.168.0.x

[Assertor]

Hi,

Zitat:

Zitat von gsh

das Problem ist das der Broadcast über den Adapter mit der jeweiligen Source-IP rausgehen muss.
Wenn ich jetzt wie du beschrieben hast die IP manuell setze dann geht der Broadcast auf allen Adapter mit der manuel festgelegten Source IP raus. Was aber wieder beim ersten Adapter schlecht ist.

Zum besseren Verständniss ein beispiel: (Packet geht mit folgender Source-IP raus)

So sieht es ohne manuelle IP aus

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 5.x.x.x

Wenn ich die IP manuel auf 192.168.0.x ändern

Hamachi-Adapter: 192.168.0.x
LAN-Adapter: 192.168.0.x

So sollte es aussehen

Hamachi-Adapter: 5.x.x.x
LAN-Adapter: 192.168.0.x

Aber das ist kein Broadcast. Beim Broadcast geht es ja gerade darum, daß ohne die Clients zu kennen mit einem festen Endpunkt (also wir als Sender) etwas an alle rausschicken. Die Clients bzw. Empfänger des Broadcasts selbst entscheiden dann, was und ob sie mit den Informationen machen.

Du kannst meines Wissens nicht automatisch den Broadcast mit abweichenden Source-IPs senden. Das geht nur in dem Du durch die Liste der lokalen IP Adressen iterierst und dann für jede IP einen Broadcast sendest (der wieder über alle Adapter rausgeht).

Das wären also bei 3 Adaptern: 3 x 3 Broadcasts :roll:

Aber das führt die ganze Logik eines Broadcasts ad absurdum. An sich ist es dann Aufgabe des Clients bzw. des VPN Tunnels hier eine geeignete Route zu finden, mit der man den Sender kontaktiert. Wenn das nicht geht, schlägt die Verbindung entsprechend fehl.

Im Falle eines normalen VPN (Win2003/2008 Server) über L2TP/PPTP würde meinetwegen der Broadcast von Source 192.168.100.1 über den VPN-Tunnel (Serverseite 10.0.0.1) an den VPN-Client (10.0.0.2) an den Rechner 192.168.100.100 gehen. Wenn jetzt der Client 192.168.100.100 den Broadcast empfängt und an 192.168.100.1 antworten will, ist der (VPN)-Router für die Durchleitung mittels des 10.0.0.x Netzwerkes zuständig.

Das kommt aber auch sehr auf den VPN-Tunnel an. Bei einfachen Sachen werden die Subnetze nicht vollständig verbunden, sondern wird NAT verwendet.

So gesehen, haben es die Hamachi-Entwickler schon richtig gemacht: Damit die Programmierer nicht in diese Falle laufen, hat der Adapter die höchste Routing-Priorität und sendet über 5.0.0.x/8 - dann antwortet der Broadcast-Client an diese IP und der Server erhält die Antwort. Dabei muß der Client natürlich auch wieder über eine 5.0.0.x gebunden sein.

Wenn jetzt Hamachi aus ist und der Adapter trotzdem läuft (und Priorität hat) gehen halt die Packete verloren. Das ist dann aber ein Problem der Hamachi Software. Logisch läßt sich das nicht anders lösen befürchte ich...

Gruß Assertor

[gsh]

Ich habe das Gefühl wir reden aneinander vorbei :wink:

Natürlich ist der Broadcast dafür da ein unbekanntes Ziel zu finden. Dieses Ziel sollte dann aber wissen wohin es das Antwort Packet hinschicken soll.
Um von dem VPN Beispiel wegzugehen bzw. Hamachi nicht die Schuld zu geben nehm ich mal ein anderes Beispiel:

PC1 <--> PC2 <--> PC3 (PC1 kann nur mit PC2 reden, PC3 kann nur mit PC2 reden, PC2 mit beiden)

PC1:
LAN: IP: 192.168.1.100

PC2: (zwei Netzwerkadapter)
LAN1: Höhere Priorität, IP: 192.168.1.200
LAN2: Niedrigere Priorität, IP: 192.168.2.200

PC3:
LAN: IP: 192.168.2.100

Wenn PC2 jetzt einen Broadcast auf allen Adapter sendet (wie du richtig gesagt hast auch der Sinn der Sache ist), dann wird (ohne spezielle Config) die Source IP 192.168.1.200 verwendet. PC1 filtert die Source IP heraus und kann nun ein Antwort Packet an PC2 schicken. PC3 erhält das Packet zwar auch kann aber keine Antwort schicken da die Ziel Adresse (192.168.1.200) für Ihn nicht erreichbar ist.

Wenn ich die IP zum senden explicit auf 192.168.2.200 setze dann würde das ganze gleich sein nur umgekehrt. (PC1 könnte nicht zurücksenden, PC3 schon).

Einen Broadcast für jede IP zu versenden ist auch ihn meinen Augen nicht zielführend.

Ich weiß nicht genau wie ihr diese Broadcast Routine implementiert habt und deshalb wäre es interessant zu wissen ob die Indys alle Adapter selber durchgehen und dann bei jedem Adapter einen Broadcast raus senden oder ob die diese Aufgabe von einer tieferen Ebene erledigt wird?

[Assertor]

Hi,

Zitat:

Zitat von gsh

Ich habe das Gefühl wir reden aneinander vorbei :wink:

Mag sein, bin gerade am Arbeiten :)

Zitat:

Zitat von gsh

PC1 <--> PC2 <--> PC3 (PC1 kann nur mit PC2 reden, PC3 kann nur mit PC2 reden, PC2 mit beiden)

PC1:
LAN: IP: 192.168.1.100

PC2: (zwei Netzwerkadapter)
LAN1: Höhere Priorität, IP: 192.168.1.200
LAN2: Niedrigere Priorität, IP: 192.168.2.200

PC3:
LAN: IP: 192.168.2.100

Wenn PC2 jetzt einen Broadcast auf allen Adapter sendet (wie du richtig gesagt hast auch der Sinn der Sache ist), dann wird (ohne spezielle Config) die Source IP 192.168.1.200 verwendet. PC1 filtert die Source IP heraus und kann nun ein Antwort Packet an PC2 schicken. PC3 erhält das Packet zwar auch kann aber keine Antwort schicken da die Ziel Adresse (192.168.1.200) für Ihn nicht erreichbar ist.

Wenn ich die IP zum senden explicit auf 192.168.2.200 setze dann würde das ganze gleich sein nur umgekehrt. (PC1 könnte nicht zurücksenden, PC3 schon).

Ja, richtig - aber das Problem hat nichts mit Indy oder Delphi zu tun. Das ist Netzwerktechnik :) Sowas wird entweder über die 1) Subnetzmaske (Subnetting/Supernetting) oder 2) Routen/Forwarding gelöst (letzteres wäre nur am PC2 möglich).

Das ist ja das bekannte Spiel wenn man LANs verbindet: Wenn alle Rechner aus 192.168.0.0 - 192.168.255.255 sich "sehen" können müssen, muß die Netzmaske 255.255.0.0 sein. Mit der üblichen 255.255.255.0 wären z.B. 192.168.100.x und 192.168.200.x nicht im gleichen Subnetz.

Es gäbe auch noch die o.g. Directed Broadcasts, die aber in RFC2644 wegen DoS-Attacken per Default nicht mehr von Routern weitergeleitet werden (sollen).

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.

Zitat:

Zitat von gsh

Einen Broadcast für jede IP zu versenden ist auch ihn meinen Augen nicht zielführend.

Ich weiß nicht genau wie ihr diese Broadcast Routine implementiert habt und deshalb wäre es interessant zu wissen ob die Indys alle Adapter selber durchgehen und dann bei jedem Adapter einen Broadcast raus senden oder ob die diese Aufgabe von einer tieferen Ebene erledigt wird?

Indy durchläuft die Adapter nicht selbst. Unter Windows läuft das im Endeffekt über die WinSocks.

Aber zurück zu Deinem Problem, geh das anders an: Der Broadcast sollte unabhängig von der Source-IP überall ankommen (ist ja eben ein 255.255.255.255 Broadcast wenn kein BoundIP vorliegt). Die Source-IP ist für den Broadcast vollkommen egal - der Client kann ja seinerseits mit einem Broadcast antworten und teilt seine IP mit. Das kann man auch schön in ein kleines Datenpacket/format (Record streamen) packen. Vielleicht noch verschlüsseln und gut ist.

Ich verstehe einfach noch nicht, was das genaue Problem ist - das ist alles mit Netzwerktechnik lösbar und hat wenig speziell mit Indy oder sogar Windows zu tun. Das ist nicht böse gemeint. Das ein VPN-Tunnel bzw. -Router Broadcasts überträgt, hängt von dessen Einstellungen ab. Genauso das entsprechende Routing.

Kannst Du etwas genauer beschreiben, was Du exakt machen möchtest (falls ich es überlesen habe)?

Gruß Assertor

[gsh]

Zitat:

Zitat von Assertor

Mag sein, bin gerade am Arbeiten :)

Ich auch :mrgreen:

Zitat:

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.

Zitat:

Zitat von Assertor

Ich verstehe einfach noch nicht, was das genaue Problem ist - das ist alles mit Netzwerktechnik lösbar und hat wenig speziell mit Indy oder sogar Windows zu tun. Das ist nicht böse gemeint. Das ein VPN-Tunnel bzw. -Router Broadcasts überträgt, hängt von dessen Einstellungen ab. Genauso das entsprechende Routing.

Kannst Du etwas genauer beschreiben, was Du exakt machen möchtest (falls ich es überlesen habe)?

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 :dp:

[Assertor]

Hi Alex,

Zitat:

Zitat von gsh

Zitat:

Zitat von Assertor

Mag sein, bin gerade am Arbeiten :)

Ich auch :mrgreen:

;)

Zitat:

Zitat von gsh

Zitat:

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:

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 :dp:

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:

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 :zwinker:

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

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:

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:

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:

Zitat von gsh

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

:thumb:

Gruß Assertor

[gsh]

Zitat:

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. :zwinker:

[Assertor]

Zitat:

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:

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:

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. :zwinker:

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:

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:

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:

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. :thumb: