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

[Niklas Elmqvist]

On Wed, 25 Nov 1998, Jon Leonard wrote:

> 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.  

Really? I must look into this. In a similar vein, would your school allow
you to turn a project like this into a commercial venture and earn money
out of it?  Why/why not? 

> Also make sure that GPL is the license you want, though that's a
> flamewar we don't need. 

Right. I can't say I have a personal preference on what license to use, as
long as it is free. And I also believe that it would be nice if all
changes, additions and modifications of the code are free as well (in
this case, I'm not sure I want somebody to take the code and start making
a profit from it). The way many American universities have developed
hi-tech software (SPICE, ) is my inspiration.

> [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.

Indeed. That was my feeling as well, but I needed someone other than me
(someone with a little more experience as well) to say it. :)

> > 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.

What are the other options, then?

> >  - 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.

Sure, but I was under the impression that UOL, EverQuest and Asheron's
Call all use big bad-ass servers. Don't they? Oh, and Quake 2 does too,
and that game allows for about 128 simultaneous players provided you've
got some good hardware. Does anyone know of the computational as well as
bandwidth loads imposed by games on the scale of large-scale Quake, UOL
and EverQuest servers?

> >  - 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.

Right, but I am thinking that it is much easier for players to hack the
clients if the client is open source. That is, UOL would probably have a
*much* harder time if all a dishonest player would have to do is change a
few lines and then recompile the binary. Having to fire up a debugger to
reverse-engineer the code or sniff the network packets to figure out the
transfer protocol probably weeds out all but the most enterprising
players. 

> > 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.

Hmmm... But the computation peers would be like a server cluster, since
they most definitely could *not* be dished out among the players? Yes,
that would certainly help in the scalability department.

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

Right. This is probably what the DoD DIS implementations do.

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

In this context: yes, they would.

> >  - 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.

Cyborgs or bots will always be a problem, and one that is hard to address. 
Hopefully, the sheer size of the scenarios will ensure that this won't
have *that* much of an influence (even if the German machine gunner has a
aimbot, he will most certainly not be able to thwart the entire D-Day
Allied landing force single-handedly).

> Jon Leonard

Btw, thanks!

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods