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

[Marc Hernandez]

On Sun, 29 Nov 1998, Greg Underwood wrote:
> At 10:06 PM 11/24/98 +0100, Niklas Elmqvist wrote:
> > 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

	'If the client detects'.  So lets say I put a proxy between me and
the server and intercept all the coll/det PDU's.  Does this mean I never
collide nor detonate?  In small games (ie <32 or so) it would probably be
fine because it is easy to detect, but larger games (hundreds to thousands
of simul. clients) it would be a nightmare.

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

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

	This answers the above I think, however I fail to see why to have
the client send a message at all (it could detect it so that it could
start the death/collide animations).

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

	Quake simply does client prediction and display.  Sadly Quake
clients have a complete copy of the map (they must for the bsp stuff to
work), as well as copies of the models.  This lead to cheats concerning
changing the models to be more visible and 'cutting' parts out of the
maps.  In team fortress this game the cheating teams HUGE advanteges.  
	So they put in CRC checks for models and maps.  As simple as this
fix is it seems to be working.
	They cant get rid of autoaim bots, but it is fairly easy to spot
(the person switches very quickly from person to person, fires in
directions it isnt moving etc).  

	Ive had an idea of just doing spot checks on the client.  Assuming
most players are not wanting to cheat, and assuming the game is designed
such that cheats on the client end are detectable (ie with the collision
stuff), would it be a good design decision to let the clients do some work
but do automated spot checks occasionally?  Then if the server detects
something it can flag it, send messages to admin personnel, kick the
player off etc.  

> -Greg

> -- 
> MUD-Dev: Advancing an unrealised future.