Second Life and Opensim use server centric model, which makes hosting expensive. Dan discusses how we are inevitably heading to more distributed virtual world simulations.
As presently conceived in Second Life and similar worlds, the
server has eminent domain over all activities that occur "on" that
server, similar to the way a website defines what a browser can do
"on" that website. For instance, if Alice, wishes to chat with her
friend Bob, and they are both on Charlie's sim (server), their
conversation is mediated by Charlie's server. Why is this so?
Primarily it has to do with the fact that Charlie's server is
probably set up on a static IP address, whereas Alice and Bob are
more likely running on home machines, behind a NAT and firewall.
This seems to be a rather poor reason for such a limitation,
however.
Alice and Bob could of course run other software such as AIM or
Twitter, or engage in a Skype call. It would be nice if this sort
of functionality were seamlessly integrated into the Metaverse, but
today that isn't the case. The SL architecture has the sim as the
core "deus ex machina", mediating, regulating, and in many ways
fabricating the experience that all users on that sim will share.
It may seem sort of natural; the sim is like Earth, and we are
standing on Earth. In reality, of course, Earth, and each of us,
are independent bodies existing in spacetime. We "stand" on Earth
simply because Earth's gravitational pull is strong, whereas our
gravitational attraction to each other is negligable. But it is
important to remember that this is a state of affairs governed by
our relative size and composition, rather than something truly
intrinsic in our relationship to each other.
Looking to first principles, is there some sort of metric or
algorithm we can use to decide how to divide responsibilities
between clients and servers? I've given this some thought, and
here's what I came up with:
- Anything that can run on the client, should run on the
client.
- Anything that can be stored on a server, should be stored on a
server.
- Communication should be terse and direct.
- To the degree possible, resources should be provided by
those who use them.
I believe these guidelines are founded on common sense. We store
things on servers so that they can be universally accessible, and
protected from the risk of corruption or loss on a single user's
machine (we assume that servers are somewhat more robust, and run
frequent backups!). We run things on the client, because that's
where the user is. It's also worth noting that there are many more
clients than servers in a typical scenario. Disk space is pretty
cheap these days, but processing power is still a limited
commodity. The final guideline -- being responsible for your own
overhead -- relates to a social aspect of the Metaverse. CPU power
is likely to remain the most precious commodity of the Metaverse
for the forseeable future. As a free-market libertarian, I firmly
believe that you can only be depended upon to be responsible for a
resource if it costs you something, and there is a penalty for
overuse. We'll see how that impacts things later on.
Let's go through some basic features of our Metaverse, and see
how this approach plays out.
* Definitions of things -- terrain, prims,
avatars
Can we store this information on servers? It seems that we can.
Indeed, Second Life does so -- at least in theory. Obviously, the
client needs to access this data in order to visualize the world.
It creates a copy of the data; this copy may even reside on local
disk (as a cache). However, the important thing to note is that the
authoritative versions of things are indeed on various servers.
Notice I say servers, plural; we are increasingly seeing data
stored not on a single server, but across the Internet. Each
individual resource we need to conjure up a scene may potentially
be located on a different machine. This is outside the scope of
this article, but whenever I refer to a "Server" holding data, it
should be noted that this might in fact correspond to various
physical machines in different places.
* Runtime behavior: avatar movement
For the most part, avatar movement is initiated on the client
(in SL, through the keypad). Avatar movement doesn't actually "run"
on the client, however; the movement command is sent to the server.
Why? Because, in SL, the server is doing physics (and often running
scripts), which affect the motion of the avatar. What if the
required movement would cause you to go through a wall? In SL, the
server has to get involved to solve this problem. It may seem the
client could do so itself, since it has information about the walls
and other elements of the environment. This approach is termed
"client-side physics", and many networked videogames, particularly
First Person Shooters, do in fact work this way. I would suggest
that, according to my guidelines, avatar movement should be purely
a client responsibility, using client-side physics to negotiate
collisions with the environment. Obviously, we will continue to
send movement information to the server, so that other users know
where our avatar actually is. Likewise, we will continue to receive
notifications of the movement of other avatars. But, what happens
when avatars collide? More on that to come out in later
articles.
* Runtime behavior: scripted prims
In SL, scripts run on the server. This is a pretty big deal, as
scripts use up lots of resources. Scripts are bound to prims, and
prims belong to users. Why not have scripts run on the machine of
the user who owns the prim in question? This relates to a concept I
call the "behavior server". In my mind, all behaviors should be
managed and, if possible, processed by the owner of the object
exhibiting the behavior. In the case of avatars, that's how things
sort of work today. However, in the case of prims, everything is
taken care of by the server. Getting back to that issue of
resources and responsibility, this is a bad situation: it's in
everyone's interest to make maximum use of the server, but it's in
no one's direct, personal interest to ensure that the server is not
overutilized. In economic theory, this is known as the "tragedy of
the commons". In Second Life, it's known as a frakked sim.
Let's think about the ramifications of scripts running on user's
machines instead of on the server. Say I have a vehicle, and I've
scripted it to act in a certain way. In the SL model, that script
(typically written in LSL, Linden Scripting Language) runs on the
sim. I might have a Heads Up Display or keyboard interface to make
it go, but this just entails parsing an input and sending commands
to the server. The server does the hard work of running the
script's logic, including code to manage acceleration, rotation,
handling, collisions and so on. In addition, under the present
paradigm, the server is probably running physics on the vehicle, to
ensure it bounces off walls, doesn't fall through the ground,
etc.
In my model, all this work is done by the client who owns the
vehicle. The client runs a script that controls the logic of the
vehicle's motion. It runs client-side physics to ensure the vehicle
stays above ground, and caroms realistically off buildings
(depending on your driving skill). The client then transmits a
sequence of object update messages to the server, which then
broadcasts those messages to the other clients who are observing
the action at that time. Assuming there are 10 clients on the
server, this scenario involves 11 messages for every 10 that would
be sent the SL way. In exchange for a slight increase in network
traffic, you get the client machines taking over a major part of a
typical sim's CPU and memory overhead.