[MUD-Dev] Re: DIS: Client-Server vs Peer-to-Peer

[Jon Leonard]

On Tue, Nov 24, 1998 at 10:06:23PM +0100, Niklas Elmqvist wrote:

[building a Distributed Interactive Simulations system as a school project]

> I am also recommending the project members to release the simulator system
> as Open Source under the GPL at the end of the project (GNU Sim?), so
> hopefully, this quite ambitious undertaking will bring something back to
> the community. You can do a whole lot with eight enthusiastic developers
> in a full year! (Despite the fact that we won't be exclusively working on
> this project.) 

Make sure your school permits releasing your project as open source.
The school I attended probably would not allow this.  Also make sure that
GPL is the license you want, though that's a flamewar we don't need.

> Enough chattering -- this brings me to the problem. The term DIS is quite
> general; for one thing, there is a DIS standard. I have some problems with
> it, though, and I am looking for justification of the deviations I want to
> make from the standard (in general, I believe it is a good read). One of
> the keypoints of DIS is that it is a strict peer-to-peer architecture,

[dishonest clients/peers problem, as in Diablo multiplayer.  Details snipped]

This is a fundamental problem.  If you can't trust the people you're playing
with, then a peer-to-peer design is worthless.

> So ATM I am seriously thinking about proposing a client-server
> architecture instead of peer-to-peer. I now need justification for this
> decision. Basically, I am looking for all the good arguments why
> client-server should be used instead of peer-to-peer as well as the
> advantages and disadvantages of each approach. Some sample questions:

These aren't the only two options, of course.

>  - Is it a sound decision (using client-server)?

For small-scale stuff, yes.  If the simulations get really big this requires
too much compute hardware and bandwidth in the main server.  If you don't
aspire to something on the scale of UOL it should be fine.

>  - Can peer-to-peer be implemented without a lot of hassle with
> 	authentication and so on? How?

It's pretty easy to authenticate who you're talking to.  It's impossible to
prove that they're trustworthy.

>  - Is it possible in an Open Source project where anyone has access to the
> 	source? 

Open source doesn't change much in trust situations.  You can demonstrate
that there aren't traps in the source code, though.

>  - Are there any large-scale multiplayer games (MMPOG, I believe they are
> 	called) which uses a peer-to-peer architecture?

Usenet, mabye?  :-)  I can't think of any games like that.  Well, maybe
card games like MTG, but they have cheating problems.

> (Besides, it is much more fun to write a bad-ass server than a lot of
> uninteresting clients, which might be justification enough... Sort of.)

> While I am at it and provided the answer is "yes, client-server is the way
> to go" I might as well ask some additional questions: 
>  - How would you keep the "distributed" in DIS with a client-server
> 	architecture?

I'd recommend a hybrid architecture.  Insteed of a single server, use a
network of computation peers that interact using the DIS protocols.  Each
of these can have several "display clients" which take care of UI stuff
without handling any computations that need to be trustworthy.

This can be set up so that all of the critical computations are controlled
by whoever set up the game (presumed trustworthy), while maintaining the
scalability of peer-to-peer design.

If you have a trustworthy network and players, just use one peer per player.

For smaller games, just use one peer as the server.  They handle multiple
clients, right? 

>  - What things can be trusted to the client? (Yes, I know there has been a
> 	rather extensive thread on that.) Does anyone know, for example,
> 	what the client-server relationships/responsibilities are for
> 	games such as Quake?

This depends on what you consider acceptable behavior.  A lot of games like
this can have "cyborg" or AI players.  If this isn't a problem, then you
can trust a fair amount of data to the client.  If it is, you have to trust
the client to some degree.  Design your system so that data you care about
can't be compromised by people/code you don't trust.

Jon Leonard