instanz des eigenen Programms im Netzwerk finden?

[Marco Steinebach]

Hallo zusammen,
Tschuldigung, mir ist kein sinnigerer Betreff eingefallen.
Ich habe eine Frage:
Mein Prog ist auf zwei Rechnern im lokalen Netzwerk installiert.
Beide haben einen idTCPServer und idTCPClient laufen, um miteinander kommunizieren zu können.
Soweit, so schön.
Gibt es irgendeine Möglichkeit herauszufinden, auf welchem Computer die zweite Instanz läuft...
Also, was ich meine ist:
Das Programm wird auf einem Rechner gestartet und, tja, scannt, das Netz, ob es irgendwo eine zwei, laufende Instanz von sich selber findet.
Ich kann ja schlecht die letzte stelle der IP-Adresse komplett durchscannen, also sowas basteln wie...

Delphi-Quellcode:

for i := 0 to 255 do
begin
  client.host := '192.168.2.* + intToStr (i);
  client.connect;
  if client.connected then // zweite Instanz gefunden;
end;

Das geht doch sicher eleganter, oder?
Für einen Tipp wäre ich sehr dankbar.
Viele Grüße
Marco

[vagtler]

https://de.wikipedia.org/wiki/Bonjour_(Apple)

https://www.google.de/webhp?q=bonjour%20delphi

[frankyboy1974]

https://de.wikipedia.org/wiki/Broadcast

[Sir Rufo]

Ja, mit einem UDP-Broadcast, den die Anwendung selber immer wieder versendet mit der Information "Was bin ich" (Service-Typ), "Wo bin ich" (IP + Port).

Also nicht suchen, sondern darauf lauschen, wer "Hier bin ich" schreit :stupid:

[himitsu]

Grundsätzlich gibt es mehrere Möglichkeiten:

• ein https://de.wikipedia.org/wiki/Broadcast
• eine zentrale Stelle, die das Ziel kennt
  • einer der Beiden ist immer an der selben Stelle erreichbar
  • eine dritte Stelle (Server oder Datei) kennt das/die Ziel(e), da sich die Programme dort eintragen/anmelden ... z.B. ala DynDNS
• alle IPs des Subnetztes durchprobieren (hoffentlich ist der Port wenigstens fest)
• die Komunikation läuft immer über einen externen/zentralen Server (Teamviewer, ICQ, MSN usw.)

[geskill]

Der Oberbegriff dazu ist Zero Configuration Networking. Der englische Artikel dazu ist noch besser. Das Bonjour Protokoll von Apple ist eine Möglichkeit dies zu realisieren. Es ist auch immer die Frage der Portabilität. Soll es nur auf Windows funktionieren oder auch auf Mac. Was passiert mit der Firewall, müssen Ports explizit geöffnet werden?

Du kannst z.B. mit Pipes arbeiten. Komponente. Beispiel findest du hier: http://stackoverflow.com/a/512796
Alternative Implementierung in einer Komponente (eleganter): http://www.cromis.net/blog/downloads/cromis-ipc/

[Marco Steinebach]

Hallo zusammen,
zunächsteinmal ganz, ganz herzlichen Dank für die Antworten - das Wetter ist so schäußlich, da kann man 'ne Menge lesen... ;-)
Ich denke, ich werde das Ganze mit UDP-Broadcasts realisieren.
Dazu noch eine Frage: bisher habe ich die Nachrichten via TCP gesendet - spricht etwas dagegen, die via UDP zu senden, dann brauche ich nicht jeweils einen Server und Client fü TCP und UDP?
Viele Grüße
Marco

[frankyboy1974]

hallo,

UDP gewährleistet nicht, dass die Nachricht auf der anderen Seite auch ankommt. Also die eigentliche Kommunikation würde ich weiterhin über TCP abwickeln.

mfg

[Photoner]

Zitat:

Zitat von Marco Steinebach (Beitrag 1329871)

Dazu noch eine Frage: bisher habe ich die Nachrichten via TCP gesendet - spricht etwas dagegen, die via UDP zu senden, dann brauche ich nicht jeweils einen Server und Client fü TCP und UDP?

Das kommt nur drarauf an ob die Datenübertragung sicher sein muss (sicher in dem Sinne dass alle Pakete ankommen).

[Klaus01]

.. wie verhält es sich denn mit Zero Configuration Networking und der Windows Firewall.
Die blockiert sowas doch in der Regel und muss dann vom Anwender freigeschaltet werden.
Oder irre ich micht hier?

Grüße
Klaus

[himitsu]

SICHER

Wenn UDP nicht für den sicheren Empfang sorgt, so kann man das natürlich auch in der nächsten OSI-Schicht nachholen, also im eigenen Protokoll eine Empfangsbestätigung, mit Rückmeldung und eventueller Neuanforderung.

[Marco Steinebach]

Hallo,
Joa, die Firewall schlägt zu, aber den Click kann man dem Anwender schon zumuten, denke ich.
Nun, ich brauche ja UDP nur für das Finden der zweiten Instanz im Netzwerk, den Rest lasse ich dann schön brav bei TCP. Dann kann ich auch, ohne weitere Programmierung, gleich darauf hinweisen, wenn's die Verbindung mal verreist...

Herzlichen Dank und viele Grüße
Marco

[HolgerX]

Hmm..

Noch ein kleiner Hinweis zu Broadcasts:
Diverse Router unterbinden Broadcasts in Ihrem Netz! Somit kann es sein, dass dein 'Hallo' ungehört im Kundennetzwerk verstummt.. ;)

Eine Server-Applikation, welche als zentrale Anlaufstelle dient hat hier den Vorteil ohne Broadcasts zu funktionieren..

[Marco Steinebach]

Hallo,
blöööd, es wäre so schön gewesen, na ja, für den Anwendungsfall wird's ohne Server gehen, ich will, hier, nur, daß beide Instanzen die gleiche Datei laden, wenn man bei der einen den entsprechenden Menüpunkt auswählt - aber dafür muß die zweite Instanz eben erstmal gefunden werden. ;-)
Eine Frage hab ich doch noch: meine Broadcast-Nachricht kommt bei der zweiten Instanz, auf der der UDPServer läuft an, und zwar, logischerweise, im UDPRead-Event. Wie kriege ich die Ip des Clients raus, von dem der Broadcast kam? Mit
aBinding.ip
jedenfalls mal nicht. :-(
Herzliche grüße
Marco

[Mavarik]

Nimm doch einfach AppTethering...

Da geht das alles fast wie von selbst...

Oh Delphi 5 - Sorry hab nix gesagt...

[frankyboy1974]

hallo,

Zitat:

Wie kriege ich die Ip des Clients raus, von dem der Broadcast kam? Mit
aBinding.ip
jedenfalls mal nicht.

Notfalls gibt der Sender seine IP-Adresse in der Nachricht mit.

mfg

[Luckie]

Wie so notfalls? Das Mitsenden wäre das einfachste.

[Marco Steinebach]

Hallo zusammen,
meine Güte, manchmal kommt man auf's einfachste nicht...
Alles schön!
Viele Grüße
Marco

[TERWI]

Ich beschäftige mich u. a. derzeit mit diesen netten Geschichte WebServices-Discovery.
Damit frage ich hier z.B. meine IP-Kameras im Netz gelegentlich mal ab.

WS-Disc. klingt/sieht vielleicht ein bischen schwierig aus - ist es aber nicht.
Im Prinzip geht das wie folgt:
Es gibt einen "Master", der viele Clienten haben kann, die er suchen kann, die sich aber auch bei ihm melden können.
Dafür gibts grundsätzlich 3 Funktionen:
- HELLO: schickt der Client, wenn er sich beim Master anmelden will.
- BYE: sendet der Client, wenn er sich verabschiedet / das Programm beendet wird / der Rechner runterfährt.
- PROBE schicht der Master in LAN - jeder Client muss mit einer PROBEMATCH antworten.

Das läuft offiziell alles via UDP mit Multicast (nur der Probematch nicht)
MC-IP ist 239.255.255.250 immer an den Port 3702 für Hello, Bye und Probe.
PROBEMATCHes gehen direkt an die IP des Servers.

Jede Message ist XML-gefüttert und führt immer (mindstens) die IP, den Port und den Typ des angefragten Clienten / des Absenders mit, bei einer PROBEMATCH-Anwort kann man bei Bedarf noch ne Menge mehr mit reinpacken wie "wer bin ich genau, was kann ich, was mach ich grade, ..."

WS-Discovery ist da relativ flexibel, und wird z.B. auch von div Netzwerkgeräten wie Druckern oder hier eben die IP-Kameras unterstützt.


Ich bastle aktuell an einer Klasse, die recht universell bei Master oder Client eingebunden werden kann/soll. Z.Zt. leider noch ein paar elementare Probs ...
Es wird eine Liste mitgeschrieben, wo alle bisher bekannten Klienten (oder auch Server) mit IP, Port, Typ, An-/Abmelde-Zeit, Status, usw. mitgeführt wird.
Damit könnte man z.B. sogar kontrollieren, wer ein/das Programm oder sonstwas wie oft und lange benutzt, ob der CLient auch wirlich "arbeitet" oder das Proggie "herum-iddled".

.... das könnte doch was für dich sein - oder ?

[Marco Steinebach]

Hallo nochmal,
... den WS-Disc schau ich mir auf jedenfall an, das klingt wirklich interessant.

Noch 'ne Frage - bitte:
im Moment finde ich meine zweite Programm-Instanz schlicht dadurch, daß ich mich mit allen IP-s von ...1 bis ...255 verbinde. Kriege ich ein connect hin, frage ich nach, ob hier auch mein Programm läuft.
Das funktioniert wunderbar, dauert aber ewig - logischerweise, dabei habe ich die connectTimeOut schon auf 150 runtergesetzt.
Geht das nicht irgendwie schneller?
Ping taugt nicht recht, weil man dafür zwingend Admin-Rechte braucht, UDP habe ich verworfen...
Hat jemand noch 'ne Idee, damit ich für den Verbindungsaufbau nicht im dümmsten fall 254*150 MS warten muß?
Herzliche Grüße
Marco

[Valle]

Im dümmsten Fall habe ich kein /24er Netzwerk und du musst >16 Millionen IPs ausprobieren. Es sei denn ich stelle auf IPv6 um. ;-)

Es gibt nur einen korrekten Weg dafür, und der wurde dir in #4 beschrieben. UDP Broadcasts sind genau für diesen Zweck gemacht.

Und als Alternative sollte es immer die Möglichkeit geben, eine IP direkt einzugeben. Alles andere ist, mit Verlaub, Mist.

[Marco Steinebach]

Hallo,
okay, also doch UDP, stimmt schon, daß war irgendwie so'ne, .., na-ja-Lösung.

Aber eine Frage:
Bei TCP kann ich folgendes, im Client, tun:
Client.IOHandler.Writeln('Hey Server, was machst du');
messageBox (Client.IOHandler.Readln); // gibt die Antwort vom Server zurück.
Geht sowas auch mit UDP, wenn ja, wie?
Ich dachte, da könnte der Client nur Senden und der Server nur empfangen und es gäbe kein Connect wie bei TCP, jetzt hab ich aber doch eines gefunden????
Hääää?
Kann mir jemand mal bitte helfen meine Vollblockade zu lösen?
Vielen Dank schonmal und vieleGrüße
Marco

[Valle]

UDP hat kein Connect, das ist richtig. Allerdings können, wie auch bei TCP, beide Parteien senden und empfangen.

Kurze Erklärung: TCP macht beim Verbinden einen sogenannten 3-way-handshake. Stell es dir vor wie "Hey Server, bist du da? Ja, bin da. Okay.". Sobald dieser handshake abgeschlossen ist, kannst du dir sicher sein, dass du eine funktionierende Verbindung zwischen Server und Client hast. TCP stellt während der Kommunikation über diesen Kanal dann außerdem sicher, dass

1. Daten in der korrekten Reihenfolge ankommen (Sequencing)
2. Daten korrekt ankommen (Checksumming)
3. du eine Rückmeldung bekommst, dass die Daten ankamen (ACK)

All dies tut UDP nicht. Auch kein Handshake. Für die meisten Anwendungen ist TCP sinnvoller, da es für dich wichtig ist, dass deine Daten richtig ankommen. Aber stell dir einen Videostream vor. Der Aufwand, jedes einzelne Paket (also im Schnitt so 1,5KiB) mit einem ACK zu bestätigen führt zu enormen Latenzen und viel eher unnötigem Traffic. Zusätzlich kann ein Videocodec oft gut damit umgehen, wenn einzelne Bits mal falsch sind oder Pakete in falscher Reihenfolge ankommen. Daher ist UDP für Videostreams oft die bessere Wahl.

Neben solchen Streams gibt es aber auch technische Notwendigkeiten. Darunter Broadcast und Multicast. Wenn du Pakete nicht an einen Server (oder einen Client) sendest, sondern an eine ganze Gruppe von Geräten (Multicast) oder einfach an alle (Broadcast), dann kannst du nicht mit jedem eine Verbindung aufbauen. Also bist du für Broadcast auf UDP beschränkt.

Zur konkreten Umsetzung in Delphi kann ich dir leider nicht helfen, aber über indy UDP Broadcast findest du sicherlich einiges an Material.

Im Gegensatz zu Sir Rufus Vorschlag, statt zu suchen, selbst zu schreien, schlage ich aber vor, beides zutun. Deine Programme (ich setze voraus dass die Instanzen identisch sind) sollten auf einem von dir gewählten UDP Port (nimm einen über 1024) lauschen und selbst über einen Timer gelegentlich mal ein "Hier bin ich, wo seid ihr" als Broadcast senden. So sollte jedes Programm auf sich selbst aufmerksam machen und dabei auch die Aufmerksamkeitsgesuche anderer beachten. Damit musst du keine Unterscheidung zwischen Server und Client treffen.

Konnte ich damit alle Klarheiten beseitigen? :wink:

[Marco Steinebach]

Hallo Valentin,
"konnte ich damit alle Klarheiten beseitigen?"
Jawoll, ;-), nein, mal im ernst: das war doch mal 'ne richtig supergute Erklärung - vielen herzlichen Dank dafür.
Läuft also, in meinem Fall, alles darauf hinaus, beides zu tun, sprich mir über UDP die IP der anderen Instanz zu suchen bzw. danach zu fragen, und wenn ich die habe, kann ich ja über TCP weitermachen, und muß nicht den Aufwand der Tests selber betreiben, wenn's TCP schon macht - zumal es hhier nix Zeitkritisches ist, wenn also für den Check ein paar Milisekunden vergehen, stört das überhaupt nicht.
Na dann - die Nacht ist noch jung ;-)

Viele Grüße
Marco

[Valle]

Zitat:

Zitat von Marco Steinebach (Beitrag 1331267)

Läuft also, in meinem Fall, alles darauf hinaus, beides zu tun, sprich mir über UDP die IP der anderen Instanz zu suchen bzw. danach zu fragen, und wenn ich die habe, kann ich ja über TCP weitermachen, und muß nicht den Aufwand der Tests selber betreiben, wenn's TCP schon macht - zumal es hhier nix Zeitkritisches ist, wenn also für den Check ein paar Milisekunden vergehen, stört das überhaupt nicht.

Genau, richtig. Du brauchst also TCP und UDP. :thumb:

Eine schnellere, nicht zentrale Lösung, fällt mir übrigens nicht ein. Ein Paket an alle und von allen jeweils eins zurück. Ohne Handshakes, ohne Timeouts. Ist doch optimal! :)

[TERWI]

Moin Marco !

Ich hab das WS-Discovery nach 100x lesen, verstehen und probieren jetzt (hoffentlich) "geblickt" und bin da jetzt mit meinem IP-Kamera-Gerümpel min. 3 Schritt weiter !
Funktioniert hier soweit mit meinen mitlerweile 10 CAMs (8x LAN, 2x WLAN/LAN) soweit recht propper.

Es gibt die Messages "HELLO" und "BYE", welche von einem Server/Proxy gesendet werden können, um deren Bereitschaft & Ende zu signalisieren.
Meine CAMs hier senden (nicht alle !) ein "Hello" nach dem aktivieren.
Ein "BYE" gibt (noch) keine von sich - das kann aber ein entsprechendes Proggie schon.

Dazu MUSS man allerdings via MULTICAST lauschen - NICHT via UDP !

Das "Hello" ist allerdings nicht mehr als ein Indiz - nicht jede CAM sendet hier komplette Daten wie in der REFERENZ beschrieben.
Man bekommt jedoch wenigstens eine IP, die man dann auf irgendeine Weise anpingen kann ...

Eine "PROBE" (oder auch "RESOLVE") vom CLienten via UDP versendet ist da schon praktischer.
Dazu muss man seinen Absendeport kennen/bestimmen, eine eindeutige UUID senden, sowie den "Typ" des angefragten Gerätes angeben. Hier für IP-Cams: "NetworkVideoTransmitter".

Dann antwortet jedes Gerät i.d.R. auch sehr zügig mit einem "PROBEMATCH" (oder "RESOLVEMATCH") und gibt ca. 2 Hände voll nützliche Werte zurück.
.... manchmal auch doppelt und 3-fach - das muss man schon ausfiltern ! Ist aber nicht wirklich schwierig ...

Wie bei HELLO geht und kommt das alles logo in (SOAP) XML zurück.
Da ich mich mit diesem "KRAM" noch nie beschäftigt hatte und auch nicht tonnenweise Packages u.a. einfügen will, hab ich kurzerhand nach kurzer Lernphase selbst was gebastelt, was in Kenntnis der Datenstruktur (XML-Konform) alle wichtigen Werte mit nur wenigen Zeilen universell extrahiert. (Bin ich sehr stolz drauf !)

Dabei herausgekommen ist eine Klasse, welche sowohl für Server & Clienten anwendbar ist und Daten nach STANDARD versendet.

Für Marco (u. a. ?!) sicher interessant:
Mit einer (kleinen) entsprechenden Anwendung unter Zuhilfename der Klasse spielt hier mein Schläppi und der PC meiner Frau jeweils eine simulierte Kamera.
Es wird "guten Tag" (HELLO) gesagt beim booten und auch "Tschüss" (BYE) beim runterfahren/Programm beenden.

Ein bischen Code gebe ich zeitnah, wenn die Klasse "aufgeräumt" und passend kommentiert ist - sonst blickt das keiner (ich auch nicht mehr in Wochen, Monaten, Jahren ...) mehr.