Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCP connection to simulation is one-way only #94

Closed
jacobythwaites opened this issue Aug 9, 2017 · 3 comments · Fixed by #103
Closed

TCP connection to simulation is one-way only #94

jacobythwaites opened this issue Aug 9, 2017 · 3 comments · Fixed by #103

Comments

@jacobythwaites
Copy link

jacobythwaites commented Aug 9, 2017

If I start an opengl simulation using python BlueSky.py, it listens on port 8888 for incoming console connections.

I connect using netcat and issue a command, as follows:

% nc 127.0.0.1 8888
airport egkk

Both the command (as issued in lower case) and the output result of the command appear on the gui console.

I would expect the output of the command to appear on the TCP connection, and the GUI console to remain unchanged.

@jooste
Copy link
Member

jooste commented Aug 13, 2017

Hi,
This is indeed the case. The telnet connection hasn't been developed beyond a very simple implementation yet. Ideally it would work the way you describe, but this requires more than a simple fix. Because stack commands can originate from several different places, where some need their feedback to be sent everywhere, and others the other way around, implementing this correctly would require a formalised way of tracking source and destination of stack I/O.

We also have the wish to change from the several different network libraries that we use now (python socket, QT network, multiproccessing.Connection) to just one library (zmq), which will also make it easier to provide TCP/UDP output streams (e.g., to drive HITL simulations). When we get around to this the stack command origin/destination issue will also be addressed.

@reube
Copy link
Contributor

reube commented Aug 23, 2017

Hi @jooste I have implemented a relatively simple fix for this on a fork (which we are keeping up-to-date with this upstream repo). I'll tidy and submit a pull request in the next few days - just writing some tests currently. It may represent a useful fix for the time being.

@reube reube mentioned this issue Aug 24, 2017
@reube
Copy link
Contributor

reube commented Aug 24, 2017

Please see #103
@jooste @ProfHoekstra

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants