Re: [GD-General] Adventures in P2P
Brought to you by:
vexxed72
From: Thatcher U. <tu...@tu...> - 2003-01-25 17:25:30
|
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 |