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

[Greg Underwood]

At 04:37 PM 11/29/98 -0800, Marc Hernandez wrote:
>
>On Sun, 29 Nov 1998, Greg Underwood wrote:
>> At 10:06 PM 11/24/98 +0100, Niklas Elmqvist wrote:

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

No.  You won't be the only one running collision detection.  Every other
client out there will be, and possibly the server if you choose to
implement that as a fail-safe.

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

That depends on how many entities each client has to keep track of.
If you anticipate large battles, you might want to have the clients
selectively filter the entities they are tracking, narrowing their local
field of battle down to a more managable number of entities.  For the
purposes of collision detection, you only want to closely watch entities
that are close enough to collide, no?

The same applies for detonation.  You only have to track munitions for
detonations, and then only the munitions close enough to really affect you,
and maybe a couple of your friends.

<...>

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

If you are going to off load all 'sensative' decisions to the server, then
there is no reason for the client to send a PDU, much less do any collision
detection.  I suppose it wouldn't be to hard to build a dumb client that
communicates through DIS PDUs, holding only a map and UI on the local side.

I was suggesting the server do detection as a fail-safe.  You could have
the server do a minial detection algorithm... or offload it to a seperate
process entirely (no one said the server had to be one app. on one machine!).

<...>

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

Spot check sounds like a reasonable approach.

Keep in mind that there is no point in solving a problem that doesn't
exist.  Don't go too overboard in trying to prevent hacking before you have
any real cases of hacking.  If it never happens, you've wasted time
developing a bad-arse detection system.  Of course, you have to balance
wasted time against potential threat.  *shrug*  I'm glad I work on 'safe'
DoD networks.  :)

-Greg