Re: [GD-General] Adventures in P2P

[Thatcher U. <tu...@tu...>]

On Jan 25, 2003 at 12:25 +0000, Andrew Sharpe wrote:

> I'm interested in the concept of P2P with one client acting as the
> server, as Mick and Phil mentioned, with the others running their
> own logic and physics but bowing to the results obtained from the
> server-client.

[...]

> There seems to be a lot of information on true Client/Server
> architectures on the net, but no tmuch devoted to P2P, which is a
> shame really as I'd imagine with most PS2Online/Xbox Live games they
> take the P2P approach.

For the networking of VR Bikes/Climbers (see
http://tulrich.com/tectrixvr) which were basically embedded PC's
hooked together in a serial loop with no possibility of a dedicated
server, we used a sort of "distributed server".  Each object in the
world has one machine that is authoritative for it.  The authoritative
machine sends periodic updates for each of its objects.  All machines
simulate all objects locally.  When an object update is received over
the network from an authoritative machine, it is pushed into the local
state.

The object partitioning basically works like this:

1. Every machine was the server for the player-object on that machine

2. The machines were ranked from 0 to (N-1) (we did this with serial
   numbers, but IP addresses should work), and the objects all had
   integer IDs.  A machine was the server for an object if

   machine_rank == (object_id % N)

It's all self-organizing; machines can enter or leave the simulation
at will, and things behave extremely robustly.  There is no one
machine that bears a disproportionate share of bandwidth.  If a
machine drops out, the rest of the simulation proceeds, and the object
responsibilities get automatically reshuffled once the machine has
been missing for a few seconds.  Everybody has an independent notion
of the world-state, so there's no one point of failure.

If machines *do* drop in and out frequently, there's definitely a
chance of objects popping around, although machines first entering the
network go into a "listen" mode for a few seconds in order to get
their objects synced to the rest of the network's state, to keep new
machines from disrupting existing distributed state.

There is the possibility for "inconsistent" interactions, although in
practice I don't think it's much worse than any networking model.

You have to trust the clients though, and it can be more complicated
to program some object types.

-- 
Thatcher Ulrich
http://tulrich.com