instanz des eigenen Programms im Netzwerk finden?

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

[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