Board index FlightGear Support Interfacing

native-fdm Error writing to socket

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

native-fdm Error writing to socket

Postby mickc » Fri Jul 24, 2020 10:12 pm

Trying to get a master-slave fg multi-computer multi-screen setup working but have hit a brick wall.

The setup

## master fg (192.168.1.100)
--native-fdm=socket,out,30,192.168.1.101,5508,udp
--native-ctrls=socket,out,30,192.168.1.101,5509,udp

## slave fg (192.168.1.101)
--native-fdm=socket,in,30,,5508,udp
--native-ctrls=socket,in,30,,5509,udp
--fdm=null

--disable-sound

Error reported on master

Error writing to socket: 5508
Error writing data.

So the problem seems to be with native-fdm.

And the log file reports:-

io:4:/build/simgear-neYw_f/simgear-2018.1.1+dfsg/simgear/io/sg_socket.cxx:345:Error writing to socket: 5508
io:5:/build/flightgear-v8AXPf/flightgear-2018.1.1+dfsg/src/Network/native_fdm.cxx:513:Error writing data.

netstat -ln reports expected results and it's not affected by ufw.

Back in the day I had 4 really old slackware slave boxes hanging off an equally old master; all working happily together!
Any help much appreciated. (Hopefully I don't need to compile my own updated fg.) Thanks in anticipation.

Linux

Linux fgmaster 4.15.0-106-generic #107-Ubuntu SMP Thu Jun 4 11:27:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux 192.168.1.100

Linux fgslave 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19 11:36:05 UTC 2020 i686 i686 i686 GNU/Linux 192.168.1.101

Linux Mint 19.3 on both

sudo apt search flightgear:-

i flightgear - Flight Gear Flight Simulator
i A flightgear-data-ai - FlightGear Flight Simulator -- standard AI data
i A flightgear-data-all - FlightGear Flight Simulator - virtual package
i A flightgear-data-base - FlightGear Flight Simulator -- base files
i A flightgear-data-models - FlightGear Flight Simulator -- standard models
i A flightgear-phi - FlightGear Flight Simulator -- Phi webfrontend

Flightgear: Version 2018.1.1
FlightGear: Build Type Dev
Built with GNU C++ version 7.3
Jenkins number/ID 0:none
FlightGear version: 2018.1.1
Revision: none
Build-Id: none
Build-Type: Dev
SimGear version: 2018.1.1
OSG version: 3.4.1
PLIB version: 185
Last edited by mickc on Sat Jul 25, 2020 2:35 pm, edited 1 time in total.
mickc
 
Posts: 7
Joined: Wed Dec 05, 2018 8:19 pm

Re: native-fdm Error writing to socket

Postby Hooray » Sat Jul 25, 2020 7:23 am

I'd suggest to check out the config used here: viewtopic.php?f=36&t=37491
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: native-fdm Error writing to socket

Postby mickc » Sat Jul 25, 2020 4:00 pm

Thanks for responding Hooray.

I'm fairly familiar with the multi computer/screen thing having used it over the years. I did take a look at viewtopic.php?f=36&t=37491 and the howto's listed there. A bit of revision never did anyone any harm. Sadly, nothing there of help.

This problem does seem to have arisen over the years for various users but a solution hasn't been published. I'd like to be able to document a reason/fix so in future it's easier. I guess there are a lot less multi-computer fg users currently, but I think that will change over time.

Obviously I've only shared the relevant config lines: The aircraft starts and flies from the desired location on the master - just sending the udp packets from the master is problematic.

Test UDP

On master (type a line of text and press enter):
$ nc -u 192.168.1.101 5508
The very quick brown fox jumps over the lazy dog 0123456789

$ netstat -an | grep 5508
udp 0 0 192.168.1.100:33228 192.168.1.101:5508 ESTABLISHED

On slave (view received message):
$ nc -ul 5508
The very quick brown fox jumps over the lazy dog 0123456789

$ netstat -an | grep 5508
udp 0 0 192.168.1.101:5508 192.168.1.100:33228 ESTABLISHED


It seems to me flightgear initially bales executing the Simgear code:-
http://simgear.sourceforge.net/doxygen/sg__socket_8cxx_source.html
sg_socket.cxx -- Socket I/O routines
Source code at lines 00325-00348

So maybe it's just a problem that's resurfaced with Flightgear Version 2018.1.1 and possibly to do with native_fdm.cxx (around line 513) the source code of which I've yet to track down.

Thanks again.
mickc
 
Posts: 7
Joined: Wed Dec 05, 2018 8:19 pm

Re: native-fdm Error writing to socket

Postby Hooray » Sat Jul 25, 2020 4:34 pm

If you can reproduce the issue using a recent version of FlightGear, that would obviously be good to know.
Also, with your background, it would obviously be great to help us update/review the existing wiki docs accordingly.
The point being, the feature is rather useful, but it's also a bit un/under-documented, many of the remaining contributors may not even be aware of it, or simply may not have access to the hardware to actually test such setups.

That is why a proper bug report (ticket / issue tracker) would be helpful.

There's currently some talks about better formalizing the whole master/slave feature, and in the process, also give it a more appropriate name :wink:

So, with your background, it would make sense to join the talks, even if you're just volunteering to help testing these multi-instance setups.

If you do have a coding background, it would obviously help to have a self-contained test case to see if the issue can be reproduced or different platforms or not.
Assuming you feel comfortable compiling a piece of C++ using make/cmake, it should be pretty easy to provide you with the pointers to customize an existing unit-test and see if the issue can be reliably reproduced or not.

The fact that you're posting here shell snippets where you are using netcat, seems actually promising ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: native-fdm Error writing to socket

Postby mickc » Mon Aug 10, 2020 8:05 pm

Just an update in case anyone else is following this and/or interested:-

It appears that the problem is primarily with the --native-ctrls input to the slave.
When starting up the slave, --native-ctrls seems to be the cause of a segmentation fault, resulting in a core dump.

If there's no slave, the master no longer has a socket open and consequently tries to write out the data, but there's nowhere for it to go.
One catch 22: The slave needs to be started after the master, but before the slave is up and running the write errors will appear until the socket has been opened.

The master definitely generates data once a socket has been created. On slave:-
nc -ul 5508 | hexdump -C
sudo tcpdump -i enp2s0 -n udp port 5508

--native-fdm fares better when run alone but the master and slave views only stay in sync when viewing directly ahead. (This may be an effect of
--native-ctrls not being enabled.)

It has been possible to run two instances of Version 2020.1.1 on the 64-bit master machine (with a bit of careful config and network tweaking) producing the same results. So it seems the problem has been around since at least Version 2018.1.1 (as shown by the slave machine) if not before.

Another observation: Once master and slave are communicating it should be possible for the combined viewpoints across all displays to be synchronously adjusted using the master machine's right mouse button ( or tab to <=> ) but this also does not work.

Next step: Raised ticket #2327 via Sourceforge.
mickc
 
Posts: 7
Joined: Wed Dec 05, 2018 8:19 pm

Re: native-fdm Error writing to socket

Postby mickc » Sat Aug 15, 2020 9:42 pm

Clearly there are now fundamental issues with the original networking modules, these seemingly having been overlooked or misunderstood by later software developers. Maybe a fundamental rethink is required, particularly regarding receiving input, especially since nobody wants deprecated code lying idle or clogging up the main loop.

Revisiting the multi-computer/multiscreen theme for a moment:-

I don't usually require the internal cockpit views:-
<draw-mask>
<aircraft type="bool">false</aircraft>
</draw-mask>

In my case the instrumentation is displayed on an additional laptop using Phi.

Some applications clearly need FDM and CTRLS data to be passed because the aerodynamics and instrumentation data are required. Experience would indicate that flightgear is successfully sending this information with the --<protocol>=socket,out,<freq>,<host>,<port>,udp syntax.</port></host></freq></protocol>

It appears to be the recipient module in Flightgear that is broken; but in many cases, it may not even be the Flightgear software that is the recipient. (e.g. Matlab)

My recent thinking is that, in a multiple display scenario, any additional display computers need data sent from the main Flightgear instance which can be interpreted and used to drive the additional display(s); if you like, post FDM calculations. These additional display computers just need a much simpler dataset to be sent, sufficient to be interpreted by a suitable dedicated module/application rather than the full Flightgear package per se. Such software would effectively monitor "view" data. All of the scenery and associated data will already have been captured by the main Flightgear instance and can be made available to the additional display computers as required. The advantage of this is that no matter how the "view" on the main computer has been generated, i.e. be it by FDM/flying or using the mouse to "look around", the total view aggregated over all displays will always be synchronised.
mickc
 
Posts: 7
Joined: Wed Dec 05, 2018 8:19 pm


Return to Interfacing

Who is online

Users browsing this forum: No registered users and 4 guests