Re: [Flightgear-devel] Notes on Flightgear voice comms

[James T. <zak...@ma...>]

On 31 Dec 2013, at 13:00, Adrian Musceac <kan...@gm...> wrote:

> I hope this wasn't too verbose to read all the way.

Thank you for the summary.

First, some observations:

- historically, we have had more offers of CPU capacity than bandwidth (or rather, servers tend to be bandwidth constrained rather than CPU constrained). However, that’s based on such a limited set of datapoints, that it is perhaps not worth basing future approaches upon.

- Personally I don’t think compatibility with standard clients is particular important, if it permitted some large gain in CPU or bandwidth use. Equally I wouldn’t disregard it for no *good* reason. (However, do you have a codec in mind which is significantly better than Speex/Opus?)

- Your point about multiple servers, split by frequency/location/something is pertinent. I’ve previously proposed to Clement a system where we use some integer hashing of frequency (eg, just the Mhz part, or int(freqInMhz * 10) to select a server name (so, fgcom120.flightgear.org, fgcom121.flightgear.org and so on). We could then use the DNS records to point these to actual servers based on load - in the simplest case all the names resolve to the same IP (one server, the present setup) and as we have more servers or load, update the DNS records to point to distinct machines. If a server goes away unexpectedly we need to update the DNS records but no client-side changes or updates are needed.

(This is a /very/ crude system, but assuming comm frequencies are reasonably evenly distributed across the frequency spectrum, it means the clients can select the correct server to contact with no intermediate lookup/query of a central server, and hence, central point of failure. Another approach would be to send an almanac/phonebook on first connection with comm-station freq+location and the corresponding server IP and phone-number to use - but this would be a custom protocol and hence more work - assuming we can’t get out-of-band data to work with Asterix/Mumble, which at present I think we cannot)

Anyway, before getting too far into technology discussions, there is the question of how to proceed. As always in open-source, it’s the people writing the code who get to decide the direction - Clement has spent considerable time on the IAXclient codebase so hopefully he will respond with his thoughts and how it relates to his plans for fgcom. Equally if you want to build a proof-of-concept for a Mumble-based system  that works in parallel, we could compare both side-by-side.

Kind regards, and happy 2014,
James