AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Werkzeuge Alternativen zu UDP und Multicast um Dienste zu finden
Thema durchsuchen
Ansicht
Themen-Optionen

Alternativen zu UDP und Multicast um Dienste zu finden

Ein Thema von chaosben · begonnen am 25. Sep 2013 · letzter Beitrag vom 25. Sep 2013
Antwort Antwort
Benutzerbild von chaosben
chaosben

Registriert seit: 27. Apr 2005
Ort: Görlitz
1.358 Beiträge
 
Delphi XE2 Professional
 
#1

Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 15:10
Nehmen wir mal an, wir haben ein LAN, in dem UDP und Multicast "verboten" ist oder "nicht unterstützt" wird. (Das sei ein Fakt, über den wir nicht diskutieren brauchen).
Und nehmen wir an, ich will mit möglichst wenig Aufwand (aka: zero-config) bestimmte selbstgeschriebene Dienste (die sich auf versch. Servern tummeln) in diesem Netz finden.

Welche einfachen (und dadurch robusten) Möglichkeiten gibt es dafür?

Eine Variante wäre ein bestimmter Hostname, der bei Hardwareänderungen angepasst wird. Das ist mir aber zu umständlich (Admin betteln) und zu langsam (DNS-Cache).
Benjamin Schwarze
If I have seen further it is by standing on the shoulders of Giants. (Isaac Newton)
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 15. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#2

AW: Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 15:51
Selbst DHCP und DNS benützen UDP als Transportprotokoll!
Die Aufgabenstellung ist daher etwas ziemlich krank (aber darüber wollen wir nicht diskutieren).
Man müsste also auf ein anderes Protokoll ausweichen - aber nicht UDP und nicht TCP.
SCTP scheidet mangels Unterstützung durch Windows ebenfalls aus.
Da bleibt wenig übrig.
Zeroconf benützt ebenfalls UDP als Transportprotokoll.

Wäre also noch ARP oder ICMP übrig wovon ARP wieder ausscheidet weil zu unflexibel.
Man könnte z.B. einen ICMP ECHO REQUEST mit speziellem Inhalt an die Broadcast-IP abschicken und der Server antwortet mit einem ECHO REPLY und der gewünschten Antwort.
Das wäre dann ein Mißbrauch des Protokolls das ja für Ping verwendet wird.

Das Problem ist jetzt dass es Windows sehr schwer macht überhaupt ICMP zu verschicken und zu emfpangen.
Der Client wäre über Windows API Funktionen noch lösbar aber der Server wäre ein echtes Problem.
Man bräuchte Adminrechte plus WinPCAP-Treiber um an WinSock quasi vorbeizukommen.
fork me on Github

Geändert von sx2008 (25. Sep 2013 um 16:05 Uhr)
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.004 Beiträge
 
Delphi 2009 Professional
 
#3

AW: Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 16:21
Frei nach Arthur Conan Doyle / Sherlock Holmes:

"When you have excluded the possible, whatever remains, however improbable, must be my software requirements."

Michael Justin
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#4

AW: Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 16:34
Gibt es ein Netzwerklaufwerk/FTP-Server mit einer festen Adresse?

Damit ließe sich ja auch so etwas wie eine Registrierungsstelle improvisieren.
Also: Sich selbst in einer Datei (Dateiname ist eigene IP-Addresse) verewigen und dann alle Rechner anstupsen, die selbst so eine IP-Datei besitzen, damit die sich auf den neusten Stand bringen.

Wenn man sich Mühe gibt, könnte man so etwas wie ein P2P-Netzwerk aufbauen, in dem alle Teilnehmer die anderen überwachen und sich über Änderungen informieren. Ein neuer Teilnehmer bräuchte nur die Adresse eines einzigen Anderen, welcher sich zur Not eventuell auch durch Raten*/Scannen im Subnetz finden lassen könnte. Wenn er noch alte Informationen besitzt, kann er dort nach dem Netzwerk suchen.


EDIT:

Die beiden Alternativen sind also eigentlich: Einen geeigneten Dienst an einer bekannten Adresse nutzen oder das Subnetz zu scannen.
Danach kann man es beliebig einfach oder kompliziert machen.

* Raten scheint bei dhcpd nicht wirklich was zu bringen. Je nach den eingesetzten System könnte es vielleicht doch funktionieren.
Im Zweifelsfall ist es für einen vollen Scan mehr oder weniger egal, welche Reihenfolge man benutzt.

Geändert von BUG (25. Sep 2013 um 17:09 Uhr)
  Mit Zitat antworten Zitat
Mikkey

Registriert seit: 5. Aug 2013
265 Beiträge
 
#5

AW: Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 17:03
Normalerweise ist für solche Dinge heutzutage SLP vorgesehen. Das muss aber mit den entsprechenden Agenten im Netz installiert werden und kommt auch nicht ganz ohne Multicast aus. Ohne UDP wird es ganz schwierig.

Ein möglicher Ansatz wäre, auf jedem Rechner einen entsprechenden Agenten vorzusehen, mit dem sich ein hinzugekommener Rechner verbinden kann, um von dem die für Deine Dienste erforderlichen Informationen zu beziehen.

Mit diesen Informationen kann der neue Rechner seine Arbeiten verrichten und wieder andere informieren. Der Anfang dürfte (Vermutung) dabei aber sehr träge verlaufen, weil viele Verbindungsaufnahmen scheitern.
  Mit Zitat antworten Zitat
Benutzerbild von chaosben
chaosben

Registriert seit: 27. Apr 2005
Ort: Görlitz
1.358 Beiträge
 
Delphi XE2 Professional
 
#6

AW: Alternativen zu UDP und Multicast um Dienste zu finden

  Alt 25. Sep 2013, 17:19
Danke für eure Ideen! Die werden morgen Teil eines erneuten Durchs-Gehirn-Stürmens.
Benjamin Schwarze
If I have seen further it is by standing on the shoulders of Giants. (Isaac Newton)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:18 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz