nVidia Driver Tweaks for Fligthgear on *nix OS

[valery]

Well, yeah ...

a short look and you have all the relays and crossfeeding and basically a static package size that has to be also applied on the client-side. See, one of the problems is, in the current "official" infrastructure, that someone logs into lets say server4 and server4 has to send all his data forward to a relay which then sends it forward to all other servers. Which most of the time works, sometimes not, which is the reason, you can see sometimes someone on some servers and not on others (aside of the blacklisting mechanism, that is another story).
So, if you are for example in server4 and the guy you are playing combat with is in server5, every little maneuver has to be sent from ->relay-server->5 and the same way back. I really think, we need to invest first a little brain-grease here before we start to change code (which btw would also mean to change at least the MP part in the client). Maybe we even need to experiment a little more.

J.

Wow, it's a really weird framework. Frankly speaking, I don't know anything about fgms, but from my own experience, you cannot sync this way, the latency (even if the 2 servers share the same provider/cloud) is to hi for a real-time game.
Perhaps could you rethink about fgms as a backend app (cgi,mod,whatever), some Apaches-like at the front, but even so, I don't think you can avoid latency if 2 users share the same space/time on 2 different servers, ie 2 different fgms instances (imagine Server1[1000users] <=> Server2[2users]).
The only workaround would be to share the data through the same diskspace, whether networked or not. Or thinking about a small EC2 farm, but of course, it will cost a bit.
My 2 cents, ... will get fgms soon in order to take an eye ..

CU

Val.

[OPFOR77]

The "official" relay server is mpserver01, for what it's worth. So you can connect directly to the "relay".

Also, if two people are connected to the same server, the traffic doesn't need to go through the relay, but instead gets propagated directly from that server.

And any fgms can act as the relay.

[jwocky]

Hi,

@OPFOR: that doesn't help, as far as I can see, either the FGMS has no internal shortcut-sync for narrow range or I haven't found it yet, I had limited time to look into it.

On a general technical level, if I would have to design it, I would hang users on an exchangable structure like a bean and if two pilots are too near to each other, lets say 20nm, put the bean-handling on the same server with a short-cut of some kind. Needs a bit more brain grease but the logic is simple. If two planes are 100nm from each other, it really doesn't matter whether they appear 100.1 or 100.2nm from each other, they won't see each other anyway. It matters with dog-fights and aar, on the short distance.

The other thing, is, this is fire-and-forget-protocol. The sender never knows whether the last message was actually received and processed. We can't do a full handshake of course, but at least in some rythm confirm. But that needs some experimenting and currently, I have no time.

On the other question, I experimented like 2 years ago with a http-server/php solution for SkyNet, but gave up after I came under hefty fire "for building my own infrastructure". The problem was, it was from the start not near to a multi-server structure. I have to see, where I buried all the stuff.

The last question to solve is, the FGMS has IP blacklisting, so there IS a mechanism of user-banning. Thus, I wonder whether we can restart the discussion about user accounts to come to a more general solution there?