< - - - >

Das geht prinzipiell schon, also auf dem selben PC 2 Programme mit UDP, allerdings kannst du z.B. nicht den selben Port zweimal als Server öffnen. Sonst kann Windows ja auch schlecht wissen wohin denn Anfragen an diesen Port gehen sollen, an Programm A oder B.

Um bidirektional zu kommunizieren brauchst du keinen Server auf beiden Seiten. Wenn du mit einem Client zu einem Server verbindest, antwortet der auf dem gleichen Kanal sozusagen.

Wenn du jetzt immer auch einen Server aufmachst, geht das nicht, weil der Port schon von dem anderen Server benutzt wird.

< - - - >

Ich kenne TUdpSockUtil nicht, hab es nie benutzt.
(Ich habe immer Indy benutzt, was allerdings auch nicht immer schön ist.)

Du könntest ja einmal im Quelltext der Komponente schauen. Sonst musst du wohl warten bis Narses den Thread liest.

< - - - >

Naja, Port und LocalPort hört sich nach dem für Client und Server an. Da darfst du natürlich nicht für den Server den gleichen nehmen wie der des Servers, der schon läuft...
Wobei bei einem reinen ClientSocket eigentlich kein Server erstellt werden sollte.

< - - - >

Moin und im Forum @markustmaier!

Jung, bist du ungeduldig, so wird das aber nix...

Zunächst mal gilt es zu klären, wie genau sich der UDP-Server, mit dem du kommunizieren willst, verhält. Es ist häufig so, dass technische Geräte mit embedded-Controllern auf dem gleichen Port antworten, von dem die Anfrage kam. Und das wiederum hat nix mit dem Server-Port zu tun (so ein paar Grundlagen zu UDP wären ja schon nicht schlecht, wenn man damit arbeiten soll...). Also, wie ist die Spezifikation des UDP-Server-Prozesses? Ist das "nur" eine Windowsanwendung oder redest du mit einem embedded-device?

cu
Narses

< - - - >

Moin!

markustmaier hat folgendes geschrieben :

Theoretisch kommuniziere ich sowohl mit dem PC als auch den Embedded-Geräten. Die Antworten nämlich auch auf meine Anfrage (Broadcast).

Urks, wie meinst du das, die Standard-Kommunikation in dem Netz ist Broadcast? Das ist ja so, als würden sich in der Firma alle standardmäßig anbrüllen, hört sich nicht gut an. Sicher, dass du da alles richtig verstanden hast? Man kann da nicht mit Unicasts arbeiten?

OK, wie auch immer, zumindest erklärt das, warum du das Programm dann nicht auf dem gleichen Recher, wie die Systemsteuersoftware laufen lassen kannst: man kann einen UDP-Socket nur an einen Listener-Prozess binden (was auch logisch ist, woher soll das Betriebssystem sonst wissen, wer die Daten kriegen soll). Fazit: wenn das nur per Broadcast geht, dann ist das so by-design, schade aber auch: ein Prozess pro Betriebssystem.

Du kannst aber doch mal testen, ob du mit der Anwendung nicht Unicast reden kannst. Dazu stellst du den LocalPort auf z.B. 61001 und den RemotePort auf 61000 und machst dann ein .Open. Wenn du dann Pakete senden/empfangen kannst, solle alles klar sein.

cu
Narses

< - - - >

Moin!

markustmaier hat folgendes geschrieben :

Also zumindest für die Authentifizierung muss ein Broadcast verwendet werden. Danach nicht mehr, sorry.

Aha, das hört sich schon besser an. Was bzw. wie wird denn authentifiziert? Ist dann die IP registriert oder was passiert da genau? Sind auch Ports Teil der Authentifikation? Irgendwie ist mir deine portbezogene Beschreibung der vorhandenen Gegenbenheiten noch zu unklar.

markustmaier hat folgendes geschrieben :

Ich habe die Ports mal so eingestellt, wie du Vorgeschlagen hast. Beim .Open kommt wieder der Fehler: Only one usage of each socket adress is normally permitted, auf API 'Blind'.

Dann mach mal einen netstat -a -n -o an der Kommandozeile des Rechners und pack das hier in den Anhang. Mal das Portmapping betrachten...

markustmaier hat folgendes geschrieben :

Also geht das wirklich nicht mit noch einem UDP Client?

Noch ist nicht aller Tage abend, wie ich schon sagte: du bist zu ungeduldig. Zumindest ich habe noch nicht wirklich raus, was da genau passiert, deine Infos sind etwas zu stark gefiltert (bewusst oder unbewusst).

markustmaier hat folgendes geschrieben :

Irgendwie muss ich das so zum Laufen bekommen. Sonst scheitert mein ganzes Projekt. Hab schon Platine gelayoutet und Software für den Controller geschreiben. Aber das es am UDP Client scheitern könnte, da hätte ich niemals dran gedacht. An der Steuerungssoftware kann ich leider auch nichts ändern.

Beschreib doch mal etwas mehr im Detail, was da wie genau zusammenhängt (aus netzwerktechnischer Sicht).

cu
Narses

< - - - >

< - - - >

Moin!

markustmaier hat folgendes geschrieben :

Ich habe mich nochmals mit der UDP Problematik befasst und kann inzwischen den Port öffnen, wenn ich einen LocalPort verwende, der ansonsten unbenutzt ist.

Öhm, genau so sollte das auch vorher gegangen sein, oder hattest du keinen LocalPort eingetragen?

markustmaier hat folgendes geschrieben :

Will ich allerdings meinen Broadcast senden, um alle angeschlossenen Geräte zu erfragen kommt folgende Fehlermeldung: Windows-Socket-Fehler: A socket operation was attempted to an unreachable host (10065), auf API'SendTo'

Mal ganz doof gefragt: du willst doch gar nicht alle angeschlossenen Geräte ermitteln, sondern lediglich deine Kommunikation authentifizieren. Also wozu überhaupt ein Broadcast? Oder habe ich dich falsch verstanden?

markustmaier hat folgendes geschrieben :

Als LocalPort habe ich jetzt 61030, als RemotePort 61005 und als RemoteHost localhost. Ich mache ein .open und danach ein .BroadcastText

Deinen bisherigen Ausführungen nach halte ich das für überflüssig, mach einfach Unicasts, das sollte schon reichen. Du willst doch nur mit der lokalen Instanz dieser Steuersoftware auf dem gleichen Rechner reden, oder nicht? Weiterhin hast du leider immer noch nicht genau beschrieben, wie denn die Kommunikation laut Spezifikation erfolgen sollte. Kann man also schlecht beurteilen, ob du das so "richtig" gemacht hast...

markustmaier hat folgendes geschrieben :

Hat jemand eine Idee woran das nun liegen könnte? Kann ich in dem Fall keinen Broadcast senden?

Was auf den ersten Blick nicht so ganz klar ist, der TUdpSockUtil verwendet für Broadcasts intern einen zweiten (Broadcast-)Socket, weil man bei einem WSA-Binding nicht transparent zwischen Uni-/Broadcast wechseln kann. Hier wird dann ein anderer lokaler Port als Absender verwendet, was normalerweise kein Problem ist. Es sei denn, es geht um Kommunikation mit embedded-Geräten, die häufig an die Portadresse antworten, von der die Anfrage kam. Das ist dann bei meinem Ansatz leider ein anderer Port, als der eingestellte LocalPort.

Gut, wie schon gesagt, das betrifft nur Protokoll-Lösungen, wo die Antwort-Pakete an den Absender-Port gehen müssen. Deinen bisherigen Ausführungen nach ist das aber nicht erforderlich, du kennst Port und Adresse des Gerätes, mit dem du kommunizieren willst. Deshalb brauchst du gar keine Broadcasts, sondern kannst direkt mit Unicasts loslegen.

Wie geht´s weiter: beschreibe doch endlich mal bitte, wie denn genau das Protokoll aussieht, an das du dich halten musst, damit du mit der Steuersoftware reden kannst.

cu
Narses