Ich habe ein Gerät mit einer öffentlichen statischen IP konfiguriert, die Fahrzeug GPS-Daten über UDP meldet. Das Gerät kann Ereignisse senden, Befehle empfangen und Befehlsbestätigungen senden.Wie setze/übergehe ich den Quellport für ein ausgehendes Datagram-Paket?
Ich habe eine App, die eine Datagramm-Socket öffnet und wartet auf eingehende Geräteereignisse auf, sagen wir mal, Port X.
Wenn das Gerät ein Ereignis sendet, meine app empfängt und verarbeitet die Nachricht kein Problem. Das Problem, das ich habe, sendet ACK'd Befehle. Aus Gründen der Skalierbarkeit/Leistung verarbeite ich Geräte-ACKs als reguläre Ereignisse. (d. h. ACKs sollten an Port X gesendet werden) Wenn meine Apps einen Befehl senden, muss die Antwortbestätigung zurück zu meinem App-Ereignis-Listener geleitet werden. Derzeit antwortet das Gerät auf die Quell-IP/den Port des ursprünglichen Pakets und nicht auf Port X, sodass meine App niemals eine Befehlsbestätigung empfängt.
Ich denke, meine Frage hier ist, gibt es eine Möglichkeit, den ausgehenden UDP-Header zu überlasten, Port X zu verwenden, obwohl dieser Port bereits an einen Socket gebunden ist? Gibt es einen Trick, den ich auf einer niedrigeren Ebene wie iptables tun könnte, um vorwärts zu portieren? Benötige ich einen Proxy oder einen Weiterleitungsagenten, um vor meiner App zu sitzen, die das Paket-Routing verwaltet? Ist es möglich, Befehle zu senden und Ereignisse über dieselbe Socket-Verbindung zu empfangen?
Was ist der beste Weg, um dieses Problem zu lösen? Meine App basiert auf Apache Camel und verwendet 2 Routen. Eine für Ereignisse und die andere für Befehle. Wenn es in Camel vielleicht einen Workaround dafür gibt?
Dank
Was wäre, wenn Sie den App-Port X in cmds auf das Gerät setzen könnten, damit das Gerät weiß, wohin es die cmd acks schicken soll? –
Haben Sie die Möglichkeit, das Verhalten des Geräts zu ändern? –
@VictorSorokin Der Gerätebefehl akzeptiert solche Daten nicht. – user2208562