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

[Niklas Elmqvist]

On Sun, 29 Nov 1998, Greg Underwood wrote:

> Ahh... what a wonderful post to reply to as my first posting on this li=
st
> in about 4 months!
>
> *rubbing hands together eagerly*

Hehe :)=20

> 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 int=
o
> 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, HL=
A is
> essentially DIS++ (DIS plus a couple extra protocols).

Oh good! Then you can be my very own DIS consultant in this project :)=20

As for HLA, yes, I've read about it, and I actually included it into my
project proposal. If you could provide a short summary, I would be much
pleased. :)=20

> At 10:06 PM 11/24/98 +0100, Niklas Elmqvist wrote:
>=20
> <...>
>=20
> >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.
>=20
> I'd be interested in seeing the proposal posted to this list, once it's
> done.=20

It IS done (I had to scramble, since the deadline was close), but I doubt
it is much good to most people around here -- it's in Swedish. However, I
will probably translate it (it looks good to have an English version as
well) and post it to this list for feedback. In addition, I am planning t=
o
put up a little DIS resource on Artoo (my webserver), where I will put a
summary of the MUD-Dev responses to my post as well as some other goodies=
,
design documents and resources. If the project is accepted (and if I am
allowed on the team), this site will grow considerably.=20
=20
In other words, if you are interested, watch this space :)=20

> I'd be surprised if you need to deviate from the standard any.  It is V=
ERY
> 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.

Really? I thought the peer-to-peer architecture permeated the standard? I
read a DIS summary somewhere (I think it was on M=E4k Technologies homepa=
ge,
<URL: http://www.mak.com>), and they listed peer-to-peer, distribution as
in targeted clients deciding on damage, dead reckoning, and so on as the
key characteristics of DIS.

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

Hmm. Are you aware of somewhere I can get a good overview and reference o=
f
the standard (preferably in PostScript or PDF format suitable for
printing)? IEEE seems determined to keep their standards off-line (I am
told that selling standards is their main source of income).

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

Ahh, good. Standards are standards, and should be followed. (Hopefully,
there is enough leeway in it to allow us to do our own design and analysi=
s
-- I'd hate to just steal someone's canned system architecture.) Indeed,
it feels a little more reassuring to have a standard to fall back on
instead of striking out on our own completely without precedent.=20

> > 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.=20
>=20
> Well, techinically, that is what the standard IMPLIES, not what it stat=
es.

Really? That's what I read on one of the summary pages, and that was what
I seemed to recall from reading the standard a while back.

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

Aha! So this means a server could be made responsible for this, not the=20
clients?=20

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

Understood.=20

[Diablo and Interstate '76 problems:]

> Aye, "this simply won't do."  I would recommend something like so:
>=20
> The clients are stripped down to simply provide the interface to the
> environment, managing their own entities, and dead-reckoning the foreig=
n
> entities, between state updates. =20

Let me get this straight -- in this setup, the clients only get notice of
the foreign entities that it can see?

> If the client detects a collision/detonation, it fires off the
> appropriate PDU. =20

But the server keeps track of collisions/detonations as well?

> The Server catches any detonation/collision PDUs, and immediately sends
> out an entity-Stop/Pause PDU. =20

This is the standard way of resolving this in a DIS? The affected clients
are suspended until the server gets around to resolve the
detonation/collision?

> 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=
.=20
> If it decides the entity is dead, it sends out an Entity Destroy PDU,
> telling everyone that the entity is dead. =20

Everyone? Would this be required in this setup using a C/S-architecture?=20
Seems to me only affected clients (i.e. clients in range of the dead
entity) need to know this.=20

> 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).=
=20
> The problem with this is increased latency between action and
> resolution.=20

Hmm, not sure I fully understand the implications of this. Are clients
still exchanging PDUs between each other in a C/S setting? I thought all
PDUs should be routed through the server -- that is, that all
communication is carried out between client and server, and not between
clients.

> > - Can peer-to-peer be implemented without a lot of hassle with
> >	authentication and so on? How?
>=20
> 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.=20

This is what I was expecting, I only needed a few outside sources to back
me up. Oh, and some useful advice, which I seem to get by the truckload!
(Thanks, all.)

> > - Is it possible in an Open Source project where anyone has access to=
 the
> >	source?=20
>=20
> 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.=20

Hmm, why is this? Sure, there may be security problems in the server, but
releasing it as free software will probably ensure that patches will star=
t
flowing in (provided the project is interesting enough to gather a
following). I can't think of any good reasons why we must keep the server
to ourselves -- in fact, my own ego gratification nerves are itching for
me to release it so that I can homestead the noosphere big-time! :)

[snip]

> > - How would you keep the "distributed" in DIS with a client-server
> >	architecture?
>=20
> 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.=20

But what good is it to let clients take care of detection if the server i=
s
doing it as well? To me, this seems a duplication of effort. Of course,
having the client do this might serve much like dead-reckoning in that it
prepares the player for what is likely to happen and reduces the impact o=
f
latency. Nevertheless, the server must at all times be regarded as the
authorative source of the world state.

> 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 serv=
er
> side, so that it doesn't trust the results completely. =20

Right. It would be a pain to have the server compute every little bump in
the road or swell in the surf for simulation purposes. This is better lef=
t
to the clients. One thing to avoid like the plague is the extreme
implementations of client-server where the client is just a stupid
interface which echoes every little player input to the server and is fed
the exact output with no or little computation on its part. In XPilots,
for example, I think the server sends the entire frame to the clients --
increasing the window size will lower your frame rate due to the increase=
d
network traffic, for one thing. This is clearly a Bad Thing<tm>. Of
course, sending anything else than a pre-rendered image to the client
paves the way considerably for client-side bots, but this is a price I am
willing to pay. Done right, this system would be independant of the
graphical capabilities of the client -- the client would render it as far
as it is capable, be it (heaven forbid!) text-only or full-blown 3D
acceleration on state-of-the-art hardware.

> 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 kno=
w
> everything about (secret doors, etc).=20

The database is a big problem. Players on unreliable and slow connections
are generally unwilling to sit around waiting while the game initializes
by downloading a few megs of map information, and keeping the map locally
on the client-side is not very appealing (still, I believe it is far
better than the first alternative). What are some other alternatives?=20
Downloading a few chunks of the world as you go along? This is probably
the most viable one, but might be tricky to implement and rather
latency-prone -- especially if we are using the same database for all
simulation type (and we are); that is, a jet fighter will cover *much*
more ground in a second than will a lowly infantry private. That said,
maybe there should be some notion of "database granularity" to allow the
soldier to hide behind that little hillock while still not bogging down
the hotshot pilot whizzing by at ten thousand feet.=20

If worst comes to worst, I have no problem with keeping the database on
the client side. Some things (such as artwork, models, interfaces and
such) will have to be kept on the client-side anyway, either by
downloading it in-game (and preferably in the background) when moving int=
o
a specific theatre of war (such as WWII, Wheel of Time or Star Wars), or
by distributing it on the CD or on a website.=20

[ snip general DIS advice ]

> 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, the=
n
> 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 =20
> interfaces.  You may be able to go a little further than that, using=20
> DIS, but you'll have to play with it and see how false info can be used
> to thwart the system.=20

It is not a totally stupid client, though. Here we have two opposing
entities -- that of distribution ("pushing as much responsibility as
possible off the server's back") and security ("making sure no-one misuse=
s
their responsibility"). Hey, we can make a Heisenberg principle out of
this yet! :)

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

Yes, they do.

I found a page containing links to the Quake network protocol at=20
<URL: http://www.activesw.com/~steve/qprotocol.html>. One of the links on
this site (<URL: http://www.opt-sci.arizona.edu/Pandora/q2/default.asp>)
has a good overview of the packets exchanged between the clients and the
server. Seems that the number of different packet types exchanged between
clients and servers is pretty low (how many PDU types are there?). Also,
the status packet includes movement data from the three last updates
(including the current one). Status packets are sent out once for EVER
FRAME. This seems a whole lot, to me, considering that the framerate must
be around 50-70 fps on high-end systems.

Does anyone know how much I/O you can get away with on standard PC
(client) hardware with a standard internet connection as well as on a
dedicated server with lots of hardware and a T1 or something? I bet there
are several ways to measure this (packets per second, throughput in bytes=
,
etc), but any rate would do.

> -Greg

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