Board index FlightGear Development New features

Possible feature: UDP repeater-server.

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Possible feature: UDP repeater-server.

Postby JazzTp » Thu Jan 08, 2015 9:17 pm

I have an idea for a possible feature for FlightGear: UDP repeater-server.

At first, I had thought of it as a nice feature for the Nimitz or the Hawkeye, but then I realized that it could be nice to be able to activate it with any aircraft: a user might be flying his favorite aircraft while sharing incoming bandwidth (*) from the mpserver to one or more client FG instances.

With this feature, a FlightGear user with sufficient bandwidth might allow other users to connect to his machine as clients (who? ideally any aircraft inside the "visibility range" given to him by the mpserver he's connected to, and optionally a list of invited users), and he would share to them the "vision" his plane has of other aircraft in the zone (NOT the scenery of course), and he would forward packets generated by clients to the mpserver he is connected to.

This might give relief to mpservers and allow users on a LAN or in the same geographic area to see each other with very low latency (the "invited users only" case could be justified when the user running the repeater-server has limited outgoing bandwidth), yet staying interconnected to the rest of the FG virtual world. During mp events, raids and other gatherings of numerous users, repeater-server instances might drastically reduce load on mpservers (**).

No change on the fgms code would be required (I believe...?), and no change in the configuration of any mpserver (no need to add any relayed server).


Secondary priority: a simpler standalone smaller program loading no aircraft and with no graphics output would allow to run this "service" on a separate machine with minimum impact on it. Anyway, the repeater-server would have to be positioned somewhere in the virtual FG reality, at some coordinates, at ground level or at some altitude, possibly not appearing on http://mpmap02.flightgear.org/ at all, or maybe with an "artificial satellite" symbol. That is the center of the "visibility area" inside which the mpserver is feeding information to the repeater-server.


Of course, users connected to one repeater-server would have their visibility radio limited to the area served to the repeater by the mpserver to which it is connected, 100 nautical miles I believe is the usual radio given by mpservers to each user (we know that it is more than enough to have lot of fun in formation flying etc., not for intercontinental flights of course, unless the repeater-server is flying with us).

TO BE CLEAR: The center of the visibility area of each client (and the repeater-server itself of course) would be the position in the "virtual world" of the FlightGear instance acting as repeater-server, not the client position.

Outside of the area, the clients of the repeater-server might still see each other (if the repeater-server does not impose any radio limits to its clients) but they would not see any other planes not connected to that same repeater-server, and their packets would NOT be forwarded to the mpserver, otherwise clients aircrafts might be unknowingly misbehaving with respect to other users that they would not be seeing but who would be able to see them. This would turn out to be like the case of users connected to one same instance of the fgms server with no interconnection with the "rest of the FG virtual world", but it would be much better than those users loosing contact from each other when accidentally flying too far from the repeater-server.

Interconnection with the clients FG instances would happen on some ports other than the usual port used by mpserver, which is currently port number 5000.

(I have problems with my ISP which is filtering port 5000 because it is used by their network UPnP setup [wrong thing to do anyway: port number only means anything when the packet reaches its destination], that's why I'm coming out with this idea, because I've been mumbling about FG port numbers.)

The user who runs the repeater-server instance would activate the feature and establish the port number through one only command line parameter (and of course he would open that port on his router and firewall).

The client feature would be activated with one command line parameter establishing the repeater-server numeric IP or dyndns name or no-ip name or whatever service the user running the repeater-server instance prefers to use (numeric IP would be fine anyway).

Users willing to interconnect might arrange through the forum or through some FlightGear irc room or through Mumble or Google Hangouts e-mail or Skype...

With secondary priority: semi-automatical "preliminaries" to interconnection might also be implemented, possibly involving FG GUI add-ons, with some chance to see a list of available repeaters, but that should happen without recurring to any mpserver and through some ports different than 5000, thus permitting that the feature allows interconnection of users (e.g. the one who is writing this text) whose ISP filters port 5000, thus giving the feature increased value.

For instance, Jamulus server instances register themselves into a dyndns central instance, I don't know the details of the protocol. I can launch it both as a server instance and as a client instance on my machine at the same time, and the client instance sees the server instance in the list of servers available worldwide.


As for outgoing packets of each connected aircraft, one of two scenarios might take place (one is better than the other):

    1. Repeater-server, best: each client's packets are forwarded to the mpserver _and_ directly to other clients (together with the ones generated by the repeater-server aircraft itself, of course), so that each client aircraft sees other clients (and the repeater aircraft itself of course) through the repeater-server; the repeater-server does not send back to any client any "echo" of the packets the client itself generates; the repeater-server sees clients directly.

    2. Pure repeater with no real server role, _maybe_ simpler but worst case: the repeater sends to each client the packets it receives from the mpserver, each client's packets are just forwarded to the mpserver, not directly to other clients, clients finally see each other only through the packets coming through the repeater from the mpserver (which means: no reduction in latency among clients). Yet, the repeater might have to filter in order not to send to any client "echoes" of the packets the client itself generates. Extreme case: the repeater aircraft itself sees its clients only by packets coming from the mpserver. In this case, scenarios 1 and 2 are not the same even when the repeater has one connected client only.



(*) and (**)
EDIT: I am no networking expert ... Let's consider for a moment the case of an internet radio station where a new client does not imply more packets to handle as a new aircraft does, because of the amount of data it sends to the mpserver. I wonder if the use of "connectionless UDP" implies that at the origin, at server level, the bandwidth required to stream to one client is the same bandwidth required to stream to more than one. Back from the radio station to FlightGear: If this is the case (shared stream), then a repeater-server instance wouldn't provide any load reduction at the level of the mpserver outgoing bandwidth, the outgoing stream from the mpserver wouldn't be diminished. If the opposite is true and "connectionless UDP" does NOT permit that the output stream of a server is shared among more than one client with no additional bandwidth load on the server, then the repeater-server would actually provide the bandwidth required for each of its own clients by forwarding to each of them the flow of information it receives from the mpserver, which is anyway the flow that the server would send to any "normal" aircraft not acting as repeater-server... the only added load on the mpserver would be due to the fact that any new aircraft in the visibility range of the repeater-server aircraft-or-whatever would anyway increment the number of packets forwarded to the mpserver and the number of packets being served back by the mpserver.
(I'd like to make a test with two or more planes connected at the same time to fgms running on my PC, watching outgoing bandwidth as they connect or detach. I hope that I'll be able to find some cooperation for a short test.)
Last edited by JazzTp on Sun Jan 11, 2015 5:20 pm, edited 7 times in total.
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm

Re: Possible feature: UDP repeater-server.

Postby Hooray » Fri Jan 09, 2015 2:07 am

you could modify/extend fgms accordingly
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: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: Possible feature: UDP repeater-server.

Postby JazzTp » Fri Jan 09, 2015 2:39 am

Hooray wrote in Fri Jan 09, 2015 2:07 am:you could modify/extend fgms accordingly


Yes, thank you, it just popped into my mind, telepathy maybe, and I've just logged in to ask about that when I saw your line, nice that you confirm that it is a viable path.

Thank you!

I have the fgms windows binary and I'm proposing to a friend to try to connect to my computer, to test if fgms can run on the same machine as fgfs.
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm

Re: Possible feature: UDP repeater-server.

Postby Hooray » Fri Jan 09, 2015 8:54 am

yes, you can run fgms locally
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: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: Possible feature: UDP repeater-server.

Postby JazzTp » Fri Jan 09, 2015 10:07 pm

Hooray wrote in Fri Jan 09, 2015 8:54 am:yes, you can run fgms locally


Thank you, yes I was thinking so: I can launch fgms (win binary) _and_ fgfs on the same PC and it seems to be ok, same port for I/O => if I stop fgms I see myself double _and_ in the pilots list, if fgms is running there's no such "echo" so it seems to be ok.

(I'm anyway proposing a friend from Denmark to connect to my IP as mpserver and meet in some airport. The problem after I eventually come to assemble some code will be the debugging and testing phase, as I can't connect through port 5000, I'll have to bother somebody, I hope that also a local Argentinian FG user will be willing to cooperate, his ISP does not filter port 5000... well by that moment it's also possible I will have bought a new notebook for other purposes too, or I might discover that a build exists of fgms for my old and nearly useless 17" Apple Powerbook G4 with Mac OS X, so I might be able to test locally, although I don't know if that would offer me the moving map vision to check if the "repeater" would be correctly visible, I don't know much of fgms yet.)
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm

Re: Possible feature: UDP repeater-server.

Postby JazzTp » Sun Jan 11, 2015 1:45 pm

Tests failed last night, Icetail kindly helped me, I was running the fgms Windows binary, I shut off the firewall, port forwarding was active from the router to the IP of the PC ethernet port (other stuff works fine that way so I suppose the router is OK), I tried binding fgms to the IP of the ethernet port, I tried binding it to 127.0.0.1, I tried NOT running fgfs at the same time and checking the server log, nothing, we could never see each other, he didn't appear in the fgms log file, I did appear in the log file any time I ran fgfs when testing in any way, binding on 127.0.0.1 or the ethernet port IP or the latter + connecting fgfs to my public IP, which was anyway resolved at router level much likely, the router shows the public IP in its wan part (it receives it from the modem which is in bridge mode), so I was NOT testing from outside with my fgfs instance.
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm

Re: Possible feature: UDP repeater-server.

Postby Hooray » Sun Jan 11, 2015 6:50 pm

According to what you stated above, fgms cannot work - i.e. you cannot expect your local/private IP to be accessible to internet users - you'd need to bind your external IP, or set up NAT/port forwarding accordingly. Basically, you really need to understand networking basics to proceed with this. Some of the most essential basics are covered in the wiki docs however.
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: 11469
Joined: Tue Mar 25, 2008 8:40 am

Re: Possible feature: UDP repeater-server.

Postby JazzTp » Mon Jan 12, 2015 4:59 pm

Hooray wrote in Sun Jan 11, 2015 6:50 pm:According to what you stated above, fgms cannot work - i.e. you cannot expect your local/private IP to be accessible to internet users - you'd need to bind your external IP, or set up NAT/port forwarding accordingly. Basically, you really need to understand networking basics to proceed with this. Some of the most essential basics are covered in the wiki docs however.


Thank you Hooray.

Yes I do have those very basic networking concepts. As I mentioned, I did activate port forwarding from the router to the IP of the PC ethernet port. Various other programs who need port forwarding are running just fine, so the router setup should be OK.

I also tried binding fgms to the public IP but binding fails... well I think the next steps might be:

    putting something in whatever file windows 8.1 uses as resolv.conf (hosts maybe like in Win XP and 7), telling the OS that the public IP is to be resolved to the ethernet port IP

    or connecting the modem to the PC with no router in between, so the PC would see the public IP directly on its ethernet port and fgms should be able to bind to the public IP (but I doubt "real" mpservers need that the shell they work in is setup anything like that).

    and/or flashing the router with the latest firmware, which I was planning to do anyway for other features and security issues (I already downloaded it, I'm inquiring on the brand forum if anything bad has been reported).


(P.D.: off topic... I just finished yet another packets capture session with Wireshark, tool suggested by polly... METAR live data was not incoming any more, I noticed yesterday... I went back to FG 3.2 and had the same problem... checked firewalls... I was ready to blame my ISP for this one too LOL... Finally, about 40 minutes ago the DNS answer for weather.noaa.gov changed to a different IP and METAR live data is OK again, so that was not a problem with my setup.)
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm

Re: Possible feature: UDP repeater-server.

Postby JazzTp » Tue Jan 13, 2015 8:47 pm

UPDATE:

After long tests last night and today with polly, and many fgms crashes, he could see me and read my text chat message, entering with his aircraft on my fgms instance, with and without my router on the connection, I could not see him nor read his text chat messages but I had both of us correctly listed in the fgms log.

We arrived at the conclusion that I must check different versions of fgms than this Windows build I got from the web, for Windows and Linux (and be able to build on my machine which was anyway the following step if I want to start modifying the code for the repeater-server purposes).
JazzTp
 
Posts: 38
Joined: Sun Aug 18, 2013 5:47 pm


Return to New features

Who is online

Users browsing this forum: No registered users and 1 guest