Hi James,
"James Palmer" wrote:
> If it is overly burdensome on framerate due to latency, I see no reason why
> a server cannont support both architectures (single and split).
[...]
> -As I investigate this proposed architecture, I plan to avoid splitting the
> FG world. I do plan to allow easy avoidance between fighters and
> non-fighters (at various levels), but I think the FG community as a whole
> benefits from a single set of servers.
[...]
> The new architecture we are proposing will not be useful if it does not meet
> or exceed the performance of the current architecture. We are well aware of
> this.
Trying to get to "the point" (TM), I'd present the now following
conclusion. This is my favourite in discussions like this one: Cutting
a mixture of different topics into respective pieces :-)
1.) In order to run every FDM on one single server (or a cluster of
servers, if you like), you'd need to design and implement an
network protocol which is smart enough to send all control input !!
to the server _plus_ the result of the FDM back to the client
without user-noticeable delay. You're relying on a two-way
communcation (loop) here which involves four transitions between
simulator and network (which, BTW, adds to the latency).
2.) Simply doing the job of collision detection on a centralized server
does not necessarily require to have a local FDM, you 'just' have
to make sure the position, velocity and acceleration data of the
aircraft is available just in time (TM ;-) - no matter how it
gets there.
3.) In case you manage to design and implement a network protocol that
meets the conditions of 1.) then it doesn't matter where the FDM is
actually running - because per your own definition you have a
network infrastructure whose latency is soo low that the pilot
wouldn't notice.
4.) If the network loop is faster than your pilot's cognition it makes
absolutely no difference if the collision detection, which is
supposed to take place on the MP server, is done at the beginning
or in the middle of the loop - per definition the pilot won't see
the difference anyway. Additionally, the visual outcome of your
enemies' action in a dogfight is always the same because this
_always_ goes:
enemies client -> MP-server -> your client
^^ step 1 ^^ step 2
If your're running a central FDM sever, then step 1 includes all
the pilot's controls and step 2 contains FDM output. If everybody
is running their local FDM, then step 1 contains FDM output as
well, instead of pilot controls - which would not make significant
difference to the latency.
Thus I don't see the point in running the FDM on the server. In
contrast:
1.) If the network latency is really sooo low that the pilot doesn't
recognize, then you're done by implementing collision detection on
the server and leaving the FDM on the client.
2.) If network latency is too large, then the collision detection will
get delayed _plus_ the pilot will feel seriously annoyed because
his own aurcraft is being rendered 'unflyable'. The outcome of this
is that you're buying mediocre collision detection for the risk of
annoying 'your' users.
Of course FlightGear would profit from every type of improvement, which
certainly includes the network protocol as well - even though I think
what we currently have in CVS is already pretty smart ! Yet I heavily
doubt that a centralized FDM server is the solution.
BTW: What are you going to do if the server has a short (or even a
bigger) outage, maybe just 10 seconds. This might affect one local
client connection, a peer connection between different carriers or
maybe the server itself. Such thing actually _does_ happen in real
network life and you have to take this into account.
If people are running their local FDM, then they will see other
aircraft freeze during this period, but they'll continue to fly along
their path. If you're running every FDM on a central server, then
_every_ pilot will see his aircraft freeze at the current location.
What a fun ....
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
