instanz des eigenen Programms im Netzwerk finden?

[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

[Valle]

Zitat von Marco Steinebach:

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.

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.