Board index FlightGear Support Interfacing

Generic property UDP input port - use outgoing one

Connecting two computers, using generic protocol, connecting with Matlab?

Generic property UDP input port - use outgoing one

Postby benih » Thu Apr 22, 2021 8:39 pm

Hello,
currently I investigate means for implementing the RDF feedback for FGCom-mumble.
The plan is to push its values to a specific property which is monitored by a nasal script, adjusting the default ADF needle position if RDF info is received from FGCom-mumble (manually this works good, already tested).

My issue is the following, and I hope someone can push me in the right direction:
  • FGCom-mumble receives UDP packets from FlightGear trough a custom protocol definition.
  • This works well and assigns a random (but stable) UDP client port for the FGFS end.
  • FGCom-mumble expects that the UDP-sender can receive on the port it sended (when RDF data capability was requested)
I however find no way to read the assigned sending client port in FlightGear, so I have no way to set it when activating the "in"-part of the protocol file and FGFS keeps listening on a random port.
Assigning a fixed predefined listening port is something I really want to avoid.


So this is the scenario i want to get to:
FGFS sends to FGCom-mumble at Port 16661. Gets random client port 12345 assigned.
FGCom-mumble sends RDF info back to port 12345.
User avatar
benih
 
Posts: 595
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: Generic property UDP input port - use outgoing one

Postby Johan G » Fri Apr 23, 2021 6:43 am

There could possibly be another way to do it.

If the callsign used in FGCom-mumble is the same as the one used on the multiplayer server (AIUI /sim/multiplay/callsign) it should very likely be possible to use the position of all the other aircraft (/ai/multiplayer[n]/callsign and /ai/multiplayer[n]/position/..).

You would probably have to make an array/hash/whatever it is called in Nasal with the aircraft within the mpserver range, and could possibly update the one the DRF receiver currently is tuned to more often. You could from there calculate direction, distance, and if need, signal strength.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6287
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Generic property UDP input port - use outgoing one

Postby benih » Fri Apr 23, 2021 10:21 am

Thanks for the idea Johan,
but this is not the problem I need to solve - this is already done just fine. Also it would restrict usefulness: not all FGCom-mumble senders are actually connected to the multiplayer network, like AM radio stations.

My current approach to solve it is to hard-assign 19991 as the fgfs listen port.
This works good and reliably, unless you have two FGFS instances or the port is in use by other software on your system already.

Therefore, the more clean solution would be to bind the listen port to the client port the outgoing packets use.
From what i see in the code, it looks (to me!) that this is just not possible because sending ports are assigned by random (or have to be fixed).
This would be solvable easily probably if the assigned client port would be exported to the prop tree, so i could query that using nasal after registering the out-channel but before registering the input channel.
User avatar
benih
 
Posts: 595
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: Generic property UDP input port - use outgoing one

Postby Johan G » Fri Apr 23, 2021 10:50 pm

benih wrote in Fri Apr 23, 2021 10:21 am:Thanks for the idea Johan,
but this is not the problem I need to solve - this is already done just fine. Also it would restrict usefulness: not all FGCom-mumble senders are actually connected to the multiplayer network, like AM radio stations.

Ah.

benih wrote in Fri Apr 23, 2021 10:21 am:[...] this is not the problem I need to solve - this is already done just fine.

Great! :)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6287
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Generic property UDP input port - use outgoing one

Postby www2 » Tue Apr 27, 2021 12:47 am

Johan G
The problems is that the current generic IO subsystem is one way only with the exception of serial that have a option for bidirectional data transfer.
I think the best way for this if Flightgear get two genetic IO medium SocketServer and SocketClient for fixing this problem.
www2
 
Posts: 284
Joined: Thu Apr 16, 2009 1:58 pm
OS: Ubuntu

Re: Generic property UDP input port - use outgoing one

Postby erik » Tue Apr 27, 2021 7:11 am

From all what I read in the code the fix should be quite easy:

Search for "get_dir() == SG_IO_IN" in simgear/io/sg_socket_udp.cxx and replace it with "get_dir() == SG_IO_IN || get_dir() == SG_IO_BI"

and

search for "get_dir() == SG_IO_OUT" in simgear/io/sg_socket_udp.cxx and replace it with "get_dir() == SG_IO_OUT || get_dir() == SG_IO_BI"

And now you should have bi-directional support for UDP. The same goes for TCP by the way.

If this works I'll push the fix to the next and 2020.3 branches.

Erik
erik
 
Posts: 1819
Joined: Thu Nov 01, 2007 1:41 pm

Re: Generic property UDP input port - use outgoing one

Postby benih » Tue Apr 27, 2021 7:26 am

How would i initiate that?
currently i register the channels with nasal:
https://github.com/hbeni/fgcom-mumble/b ... #L124-L137
User avatar
benih
 
Posts: 595
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: Generic property UDP input port - use outgoing one

Postby erik » Tue Apr 27, 2021 7:33 am

I haven't worked with socket I/O in Nasal but I think you just would do "generic,socket,bi" (once) and then connect to, and receive from the same connection.

Another option is to keep the code the same but give both the same port number.
This wouldn't even require the change in SimGear.

Erik
erik
 
Posts: 1819
Joined: Thu Nov 01, 2007 1:41 pm

Re: Generic property UDP input port - use outgoing one

Postby www2 » Tue Apr 27, 2021 12:50 pm

@Erik

The problem is that current socket I/O don't have the concept of a bidirectional data and a other problem is that "generic,socket,in" act like a server and "generic,socket,out" act like as a client.
The best way what i say in my early post is that we add two new socket subsystems "generic,socket_server,bi" and "generic,socket_client,bi" to fix this problem it is little more work than you fix but is more easier to understand than in the current system.
www2
 
Posts: 284
Joined: Thu Apr 16, 2009 1:58 pm
OS: Ubuntu

Re: Generic property UDP input port - use outgoing one

Postby erik » Tue Apr 27, 2021 1:50 pm

Lets wait for the result of what I proposed before trying to do the same with new code.

Erik
erik
 
Posts: 1819
Joined: Thu Nov 01, 2007 1:41 pm

Re: Generic property UDP input port - use outgoing one

Postby www2 » Sun May 02, 2021 5:31 pm

erik
I don't agree with you about this point.
The current socket interface is similar as a generic property for files that flightgear can only handle one direction traffic and i think the code is base on the serial port or file handler.
What i in my early post say is that i like to see that flightgear have a proper genric socket server/client where you need have two way communication over two ports.
I think about the telnet server that is a other code path than the current the generic socket server/client.
Beside i have done some tests yesterday and i gen not get this working the bi command on flightgear and telnet client (on the same pc) that is connect to flightgear.
www2
 
Posts: 284
Joined: Thu Apr 16, 2009 1:58 pm
OS: Ubuntu

Re: Generic property UDP input port - use outgoing one

Postby benih » Sun May 02, 2021 5:38 pm

I think, i would just need the port numbers reported in the /io/channels/.../ prop tree, so i can read that out and assign dynamically via nasal.
User avatar
benih
 
Posts: 595
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX


Return to Interfacing

Who is online

Users browsing this forum: No registered users and 1 guest