Moin Narses,

wegen seiner Übersichtlichkeit mag ich die SockUtil-Komponente sehr.

Nun bin ich auf folgendes Problem gestossen: Ein Netztwerk-Device, welches UDP-Datagramme zur Identifikation im Netztwerk benutzt, sendet seine Antworten an DEN REMOTEPORT gerichtet, VON DEM die Anfrage ausging.

Wie bring ich es zustande, den Localport der Komponente so zu setzen, dass er mit dem von der WSA zugeteilten Sendeport übereinstimmt?

Mit freundlichen Grüßen
Ulrich Bangert


Moderiert von Christian S.: Topic aus Open Source Projekte verschoben am So 27.07.2008 um 16:50

Moin und im Forum!

ulliban hat folgendes geschrieben:

Ein Netztwerk-Device, welches UDP-Datagramme zur Identifikation im Netztwerk benutzt, sendet seine Antworten an DEN REMOTEPORT gerichtet, VON DEM die Anfrage ausging.

Sendest du Broadcasts?

ulliban hat folgendes geschrieben:

Wie bring ich es zustande, den Localport der Komponente so zu setzen, dass er mit dem von der WSA zugeteilten Sendeport übereinstimmt?

Für Unicasts kein Problem, du gibst ja mit der Eigenschaft .LocalPort eben diesen vor. Bei Broadcasts allerdings wird intern ein weiterer Socket verwendet (der dann einen zufälligen Port zugewiesen bekommt), weil man einen gebundenen UDP-Port nicht mehr bzgl. der Broadcast-Option anfassen kann.

Naja, ich sollte das Ding wohl wirklich mal langsam renovieren... (und dieser Punkt steht da auch schon länger auf der Liste, so ist das nicht )

cu
Narses

Hallo Narses,

zunächst mal danke für die schnelle Antwort.

Und: Ja leider, es handelt sich um Broadcasts. Es geht darum, bevor man mit einem Device auf TCP-Ebene redet, zunächst zu ermitteln, wie viele von der Sorte im Netzwerk überhaupt vorhanden sind und wie die MAC-Adressen und die IP-Adressen beschaffen sind. (MAC-Adressen deswegen, damit man die Geräte auf der UDP-Ebene noch umkonfigurieren kann).

Dabei erzeugt der PC ein "Identify"-UDP-Paket (Boadcast) auf einem bestimmten Port und die Devices antworten ihrerseits mit "Hier-bin-Ich"-UDP-Boadcasts. Leider wird aus Gründen, die mir nicht bekannt sind, auf dem Rückweg nicht ein FIXER Port benutzt sondern derjenige, aus dem die Anfrage kam, obwohl dies die Sache zu erschweren scheint.

Bin in dieser Sache für jeden Hinweis dankbar, der es mir gestattet

a) entweder bei den ausgehenden Paketen den Port einzustellen

oder

b) zu ermitteln, welcher Port benutzt wurde.

Ich kenne von der ganzen Problematik wohl viel zu wenig. Wie kann ich mich über die Problematik "Automatische Portzuweisung bei Broadcast" klugmachen???

MfG
Ulrich Bangert

---Moderiert von Narses: Beiträge zusammengefasst---

Hallo Narses,

vielleicht noch eine Info hinterher. Bin darauf nicht selber gekommen sondern über einen Thread in einem anderen Forum:

Wenn man eine Indy-SERVERKOMPONENTE (!) dazu benutzt, einen Broadcast zu verschicken, so bekommt dieser den "DefaultPort" als Sourceport zugewiesen, also genau was ich will. Die eigentliche Problematik wird mir damit allerdings immer unverständlicher!

MfG
Ulrich Bangert

Moin!

ulliban hat folgendes geschrieben:

Ja leider, es handelt sich um Broadcasts.

Das hab ich mir schon gedacht.

ulliban hat folgendes geschrieben:

Leider wird aus Gründen, die mir nicht bekannt sind, auf dem Rückweg nicht ein FIXER Port benutzt sondern derjenige, aus dem die Anfrage kam, obwohl dies die Sache zu erschweren scheint.

Das ist ein bei embedded-control-devices häufig anzutreffendes Verhalten. Vorteil: es ist keine Konfig nötig, um den Rücksendeport festzulegen. Nachteil: man könnte das nicht wollen...

ulliban hat folgendes geschrieben:

Wenn man eine Indy-SERVERKOMPONENTE (!) dazu benutzt,

Wenn du bei der Problematik schnell weiterkommen willst, dann wäre das auch an dieser Stelle mein Rat: steig auf die Indy-Kompos um, da kannst du das von dir benötigte Verhalten für die Gerätchen einstellen.

ulliban hat folgendes geschrieben:

Die eigentliche Problematik wird mir damit allerdings immer unverständlicher!

Das eigentliche Problem ist die WinSock-API, die es nachträglich (=nach dem bind) nicht gestattet, die Broadcast-Option bei einem UDP-Socket zu setzen. Dazu muss man das binding wieder lösen und neu binden... Das wollte ich aber im TUdpSockUtil nicht (was ein paar Gründe hat, u.A. das bis dahin noch wartende Pakete verloren gehen), also habe ich einfach intern einen weiteren Socket für die Broadcasts verwendet. Solange man mit (PC-)Programmen kommuniziert, ist das idR kein Problem, da man hier sehr einfach die Konfiguration der Sockets verändern kann, allerdings gibt es damit Probleme bei embedded-control-Geräten, die das o.g. Verhalten an den Tag legen. Zugegeben, an diesen Aspekt der UDP-Kommunikation habe ich bei der Entwicklung der Komponente nicht gedacht, mir ging es damals hauptsächlich darum, dass die Delphi-UDP-Standard-Kompos (in D7) einen Bug haben und gar keine Absender-Infos zurückliefern. Naja, wie gesagt, wenn sich die Gelegenheit ergibt, werde ich die Kompo mal "runderneuern" (hab da selber schon eine kleine Wunschliste ).

cu
Narses

Trotzdem vielen Dank für die Mühe, ist bei weitem nicht selbstverständlich, so ausführlich zu antworten!

MfG
Ulrich Bangert