Srv records aus dem dns abfragen unter vb.net

Hi,
schaum mal C# .NET DNS query component
Ich habs nicht weiter getestet, aber es hörts sich vielversprechend an. Das kann man sicher ganz einfach in VB.Net konvertieren.

Ansonsten wäre da noch ne Abfrage über WMI, wobei ich aber jetzt nicht auswendig weiß, welche Rechte dafür erforderlich sind.
DNS WMI Provider Samples—Managing DNS Resource Records

Oder einfach NSLOOKUP ausführen und die Ausgabe umlenken und einlesen.

E.

Hi,

ich würde auch auf die Config-Variante setzen und - falls du mehr als zwei Server verbinden möchtest - einen Master definieren bei dem sich alle anderen Slaves anmelden und im Gegenzug die Adressen der anderen Slaves erhalten. Dabei wäre der Master ein ganz normaler Slave mit all seinen Aufgaben der allerdings zusätzlich als Verbindungsbroker agiert. Damit wäre der Aufwand beim Einrichten eines Clients überschaubar und du sparst dir das ganze Broadcast-Gedöns. Das Verteilen von Messages (z.B. "Slave hinzugefügt" oder "Slave entfernt") könnte dann beispielsweise über SignalR laufen.

Atze

Einfach lesen

Um Himmels Willen!

Ok - das müsstest du jetzt mal näher erklären... Bei P2P muss DNS zum Einsatz kommen? Glaubst du allen ernstes das es irgendwo einen SRV-Record für BitTorrent gibt? Oder für das eMule-"Protokoll"? Ich bin mir sicher die Anwälte würden sich freuen und liebend gerne solche Records bereitstellen - aber ich vermute mal das es nicht im Sinne des Erfinders ist.

Wenn du nur deinen eigenen Server konfigurieren kannst - dann hilft dir DNS ja auch nicht. Weil du dann nur deinen DNS konfigurieren kannst - und ob ich nun auf meinem Server ne Config-File ändere oder nen DNS (der ja auch nicht wirklich was anderes als Konfigs enthält) macht keinen grossen Unterschied.

Also - was dir bleibt ist entweder _ein_ zentraler Server bei dem sich die Clients registrieren. Du kannst es natürlich rekursiv aufbauen: D.h. Client 1 fragt den ersten Server an. Dann kommt Client 2 und bekommt alle Clients von Client 1 UND dessen Adresse. Dann fragt der alle Clients an die er von Client 1 bekommen hat (oder eben eine Teilmenge) und bekommt von denen wieder die Clients. Selbstverständlich übermittelt er auch jedesmal seine Liste - und jeder Client pflegt halt eine Liste mit Clients die er kennt (um duplikate auszuschliessen). Wenn du diese Liste jetzt noch auf deinem Client speicherst und er eben nur beim ersten Start (mit leerer Liste) den Server benötigt hast du es bereits. (Was natürlich den Spass daran bringt: Dafür zu sorgen das du mit diesen Clients weder irgendwelche Loops erzeugst noch irgendwann soviel Traffic für die IP-Listen hast das nix anderes mehr durchkommt).

Natürlich kannst du dir sowas auch mit nem SRV-Eintrag bauen - keine Frage. Aber dann bist du noch keinen Schritt weiter da du ja immernoch irgendwo deine Listen pflegen müsstest. Und DNS wäre hier aufgrund des Cache eine eher bescheidene Wahl für ein P2P-Netz bei dem sich die Anzahl der Teilnehmer naturgemäß schnell ändern kann (nicht nur bei Filesharing auch durch z.B. Disconnects bei dynamischen IPs).

Ich finde die Idee mit diesem SRV record gar nicht so dumm. Kann man zumindest versuchen.

Ich bin eher bei @maretz und denke dass ohne zentralen Server schon das Konzept zum Scheitern verurteilt ist.

• Szenario 1 = P2P im public internet: Es hat ja keinerlei Informationen über andere Server. Bleibt also nur das Abfragen auf Verdacht. Ganz schlechte Idee.
• Szenario 2 = P2P im privaten Netz: Selbst wenn die verantwortliche Stelle/Person das genehmigt (was ich stark bezweifele, da es dafür schon erprobte Lösungen gibt, z.B. DFS) wird das Abfragen des AD nach möglichen Objekten und die daraufhin notwendige DNS-Abfrage das Netzwerk viel zu stark belasten (da es ja von jedem Server und logischerweise auch in Intervallen erfolgen muss, um neue hinzugekommene und verschwundene Server zu identifizieren).

Wenn er das Objekt kennen muss dann kannst du dir den SRV-Record aber auch sparen. Und nur weil Standards wie LDAP und SIP das so machen heißt das noch lange nicht dass du mit deiner P2P-Bastelei derartige Konfigurationen notwendig machen solltest. Das würde meines Erachtens auch nicht unbedingt zur Attraktivität deiner Lösung beitragen.