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

[Greg Underwood]

Ahh... what a wonderful post to reply to as my first posting on this list
in about 4 months!

*rubbing hands together eagerly*

I've been working with those DoD DIS networks you mentioned for about 2
years now, so I thought I'd chip in my $0.02.  You may want to look into
HLA, instead of DIS, btw.  DoD is cutting all funding to all DoD DIS
projects, and shifting it over to HLA.  However, as I understand it, HLA is
essentially DIS++ (DIS plus a couple extra protocols).

At 10:06 PM 11/24/98 +0100, Niklas Elmqvist wrote:

<...>

>Here's the situation:
>I'm currently drafting a proposal for a group project course me and my
>fellow classmates will undertake next year. This course will include a
>range of several different projects which all students will be able to
>choose from -- I am aiming to contribute one of the project ideas.

I'd be interested in seeing the proposal posted to this list, once it's done.

<...>

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

I'd be surprised if you need to deviate from the standard any.  It is VERY
broad, and any *fully* DIS compliant product should be maliable enough that
you can do a lot of what I think you want to do for this project.

>One of
>the keypoints of DIS is that it is a strict peer-to-peer architecture,
>which means that there is no central server which makes the decisions and
>calls the shots.

Yes and no.  There are simulation control PDUs which can be sent (stop,
start, destroy entity, create entity, etc), and I believe there is a
concept of a simulation controller within the standard (I'd have to go into
work to get my copy).  You should be able to make a Client-Server
architecture out of a DIS system.  It is mostly implemented as
peer-to-peer, but is not so by design of the standard.

> For example, in the DIS standard, the shooting client is
>responsible for reporting the shot and the ballistics to the targeted
>client, but it us up to the targeted client to decide whether the shot is
>a hit or not, and the extents of the damages. 

Well, techinically, that is what the standard IMPLIES, not what it states.
All it states is that the Detonation PDU has to be issued from the
simulation that detects the detonation (note that this does not have to be
the simulation controlling the entity that detonated).  It is a common
(and, in a trusted network, safe and easy to implement) assumption that the
simulation controlling the targeted entity resolves the damage.  However,
if you wanted to have a Client-Server architecture, you could have the
simulation controller resolve all damage and send out sim-control PDUs to
enact the proper results.

>In a trusted network
>environment (such as the "safe" LANs the US DoD no doubt is using DIS on),
>this is no problem.  To me, however, this instinctively feels like a big
>stumbling block in an untrusted network such as the Internet -- horrible
>visions of Interstate '76 and Diablo multiplayer rise up to haunt me. In a 
>naive DIS implementation running on the devious Internet, clients could
>easily be hacked (especially if the client is Open Source) and modified to
>always tell the shooter that the shot missed (or that the damages are
>minimal). Clearly, this simply won't do. (Yes, one in Raph's collection of
>laws, the one about clients being in the hands of the enemy, does spring
>to mind.)

Aye, "this simply won't do."  I would recommend something like so:

The clients are stripped down to simply provide the interface to the
environment, managing their own entities, and dead-reckoning the foreign
entities, between state updates.  If the client detects a
collision/detonation, it fires off the appropriate PDU.  The Server catches
any detonation/collision PDUs, and immediately sends out an
entity-Stop/Pause PDU.  Once it resolves the collision/detonation, it sends
out a PDU (can't recall the name, I think it's an Entity State PDU, but it
might be a special PDU) to update the targeted entity, and then a
Start/Resume PDU.  If it decides the entity is dead, it sends out an Entity
Destroy PDU, telling everyone that the entity is dead.  The clients would
have to be set up to ignore all PDUs from any entity they didn't receive a
Start PDU for (to prevent hacking of the client).  The problem with this is
increased latency between action and resolution.

>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:
>
> - Is it a sound decision (using client-server)?

Yes, I think it is a sound decision to use a Client-Server approach.

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

Not in an unsafe network.  Any time the client is out of your control, you
have to assume it will be hacked to your worst detriment.  Therefor, you
can not trust the client to tell you anything truthful.

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

Only as a Client-Server model.  And as long as you, and/or trusted
flunkies, are the only ones with access to the server code.

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

Not successfully, to my knowledge.

<...>

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

Distrubuted does not mean "evenly distributed".  The clients can do action
detection, just not resolution.  As long as all clients AND the server are
doing detection, and the server's resolution algorithms take into account
the possibility of false/innacurate detections, you should be safe.  You'll
have to assume that any detections made by the server are accurate.

You can probably allow the client to handle modeling of motion for the
entity(s) it controls.  Just put some simple reality checks on the server
side, so that it doesn't trust the results completely.  The down side to
this is that it requires that both client and server have the same database
to describe the environment.  You could accomplish this through use of the
Info PDUs, to send info about the DB to the clients, if it is too large for
the client to have a complete copy of, or there are parts of it that you
don't want the client to know everything about (secret doors, etc).

You'll also have to be able to handle a client that refuses to listen to
the sim control PDUs from the server.  I'd reccomend an Entity Destroy PDU
for all the entities that client controls, effectively removing it from the
loop.

The only situation I can envision that would get around that would be all
clients ignoring the server.  If that happens, I'd say the person that
pulled that off deserves to enjoy it.  The client should be a sufficiently
stripped down DIS sim that the amount of work required to allow all the
clients to ignore the server would be collosal.  That and the resulting sim
would be peer-to-peer with all the inherant problems therin.

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

Dunno what Quake does, but I don't think the client does a lot.  I've seen
my position change as a result of lag (IE: I walk down a hall, then I'm
back at the start of the hall, and walk down it again, repeat 4-5 times
while the lag clears).  Quake clients appear to be simple interfaces.  You
may be able to go a little further than that, using DIS, but you'll have to
play with it and see how false info can be used to thwart the system.

Come to think of it, I bet Quake clients have a full copy of the map, too.  ;)


Ahh... It's good to be back.

-Greg