[gameprogrammer] Re: FPS with distributed servers
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Sat, 5 Mar 2005 20:35:17 +0100
On Saturday 05 March 2005 19.14, Infinite Possibilities wrote:
[...]
> The main server advantage I was thinking of would be that you don't
> have any server boundries. And if you balanced the load properly I
> think you would see less lag as well. The reason I say this is that
> there would never be a server were everyone was on that was trying
> to do everything while your the other servers sit mosetly unused.
Speaking of load balancing, I've been thinking a bit about it in terms
of programming models.
How about taking OOP to the next level, and allow objects to migrate
as needed, as load changes?
With traditional methods, one would implement this by having each
"object" be a thread, and use some form of IPC for inter-object
communication. However, that means there's a rather high penalty for
interaction, even when objects are on the same server. IPC can be
rather light weight in a proper OS, but it's still many times heavier
than just making method calls.
However, if you base the inter-object communication on an API that
allows easy replacement of implementations behind interface instances
(for example, interfaces could be structs of function pointers), and
inform some central scheduler whenever communication takes place, you
can transparently monitor communication activity and move objects to
other threads (potentially other CPUs on SMP/multicore systems) and
even other processes.
(Unless you do some serious low level magic, as some cluster support
kernel extensions do, you'll need objects to support migration
explicitly - but you can do that with a serialize()/deserialize()
interface, which is very handy for things like saving and restoring
games as well...)
Now, if you implement the inter-object interface such that you don't
care about the return values (or at least not use need them right
away), the communication can be asynchronous. That is, use
event/message based communication. This can be implemented very
efficiently with only in-line code for normal situations. (I have a
simple implementation of such a thing in Audiality, for sample
accurate control without splitting buffers.)
Event based asynchronous communication can actually *improve*
performance even in single threaded systems, since it allows chains
of events to be processed in tight loops, without function calls or
reloading function state for each event.
Of course, it also happens to be perfect for IPC, because you can
avoid this horrible roundtrip behavior of normal RPC calls.
The bad news is latency. As long as all objects are in the same
thread, you can essentially code as if you were using function calls,
because there is a guaranteed worst case latency in terms of logic
time. (Something like, "Any object you send a request to will have
replied before you run again.") Once objects start migrating to other
threads, other processes or other machines, there is no truly useful
definition of the response time. You can't count on getting
information back, or having objects respond, within the current time
slice, logic time tick or watever your time base is.
I think this could be dealt with by means of timestamps. (Just like
audio plugin systems use timestamps to make event handling sample
accurate while processing tens, hundreds or thousands of samples per
plugin process() call.) Stamp events with the current time, so the
receiver knows what time/state you're talking about, so it can roll
back and reevaluate if needed.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
