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

[Niklas Elmqvist]

Sorry for the late reply, but I am currently at my parent's home and
surfing on a crappy 14.4k modem...

On Wed, 25 Nov 1998, J C Lawrence wrote:

> On Tue, 24 Nov 1998 22:06:23 +0100 (MET)=20
> Niklas Elmqvist<d97elm at dtek.chalmers.se> wrote:
>=20
> > With enough flexibility built into the system, I am envisioning
> > sort of a universal battlefield simulator able to support
> > simulations of all kinds of battles -- why not pop onto the net,
> > take a look at the current scenarios being played out, and then
> > jump into a simulation of Omaha Beach at D-Day, for example? Or
> > why not the Battle of Endor, Thermopylae, Hastings or Gettysburg?
>=20
> AI's dynamically and transparently replaced in an ad-hoc manner by
> humans such that protagonists are unable to transparently determine
> if their opposition is AI or human?  Neat.

Indeed! If no human players are on, the entire battle would unfold under
the control of a lot of AIs... Or maybe not, since we don't want to waste
a lot of computing time when there is no one there to witness it ("does a
tree falling in a forest produce sound..." and all that stuff) -- some
kind of statistical number-cruncher could be brought into play instead.

More hype:  The idea is to allow for a lot of different types of
simulations cooperating on the same battlefield. It all boils down to
human players generally not wanting to play cannon-fodder roles such as
infantry charging against a machine-gun nest (though I expect some player=
s
would like to sit behind that machine-gun instead), so the AI is there to
take care of that. In addition, the AI will make it possible to run
large-scale scenarios where only a small fraction of the individual units
are controlled by human players. In addition, it would be nice if just
about *any* role on the battlefield could be filled by a human player --
in the D-Day scenario, some people could jump into P-51:s and scour the
skies above the battlefield, others could man the guns of the battleships
cruising the coastline (all right, boring job, but it would be there
nonetheless), still others could play the defending Germans in the
trenches and bunkers, and so on. The blood-thirsty Quakers might step in
as lowly soldiers with a familiar first-person view and be allowed to fra=
g
to their heart's content (dying would respawn the player in a new body),
while the strategically minded would be presented with a StarCraft-like
overhead interface allowing them to order troops around, spot weaknesses
and launch attacks (AI-controlled units would follow orders
unquestioningly, while player-controlled units would get a message and
some kind of visual cue as to the commanding officer's orders -- these
could be ignored, of course).=20

Needless to say, this might require a range of different clients to
support all of these roles, but they could hopefully be built around
the same skeleton client structure (some of the client stuff could
probably be solved by dynamically loading functionality from shared libs).
Also, I would like to be able to support different types of scenarios --
not just D-Day, but also Star Wars fleet engagements, Tolkienesque fantas=
y
battles as well as claustrophobic Alien fights.

Ahem. Looks like I got a little carried away up there, but now you know :=
)=20

> > That's the idea, anyway. Of course, I am concealing all of these
> > entertainment aspects in a cloak of respectability; I am not
> > entirely sure everyone would approve of a game project! ;)
>=20
> The better profs (and contract agencies) tend to realise that games
> have more demanding technical and performance restrictions than
> business-related projects. =20

Right you are. Last year's projects actually included a strategy game, so
I definitely have a chance of having my project proposal accepted!

> DIS has a number of problems for this type of application which can
> be mostly summarised into:
>=20
>   -- Assumes that all nodes are equally trustworthy.
>   -- Assumes that bandwidth is free.
>   -- Assumes that nodes have infinite resources.
>   -- Has no explicit security model (not even an entrance gatekeeper).

Ahh. Thanks. This neatly summarises the 'gut feelings' I've had about
things that must be addressed in the standard.

> Intel used to have a high level discussion of the problems of peer
> based designs for multiplayer games, most of which translates into
> factorial bandwidth requirements, but they've removed it
> unfortunately (used to be at
> http://developer.intel.com/drg/hybrid_author/cookbooks/games/).

Yes, what a shame. It has been removed, and the redirection is just to
their main page.

[ snip peer relationships ]

>   W need not have any relation to V, and at any instant the actual
> values for both are not only unavailable, but a pseudo-heisenberg
> ensures that any data you have is stale dated and of uncertain
> relevance to current conditions (ack latency).

Ahh, familiar stuff! Thanks for bringing Heisenberg into this, although I
am not exactly sure how it applies... :) Seems to me, there should be two
different entities in conflict (as in position and impulse in the real
Heisenberg principle)? Latency and...?

[snip bandwidth-consuming reactive status data transmissions]

> And no, you can't use IP multicast/broadcast as a carrier for your
> games (alas).

This is because the internet as a whole does not support it or does not
support it very well? Multicast does seem useful.

[snip SGI multicast backbone example ]

> Conversely moving to a client/server model allows the server to act
> as a latency mediator (appropriate use of predictive algorithms
> comes in *really* big here). =20

Seems to me, in a peer-to-peer architecture, each client is essentially a
server at the same time (duh). This means that all clients must be able t=
o
handle a lot of bandwidth and computation. With the client-server arch,
the server (which probably is a *lot* bigger than the client in terms of
computing power and bandwidth) does the dirty work and then dishes the
information out to the relevant clients (so that client X only gets statu=
s
messages of the units it can see, not *all* of the units in the world). O=
f
course, this means that some of the 'distributed' in DIS is lost.

[ Interstate '76 and Diablo cheating: ]
> Bingo.  Without a trusted something doing sanity checking its not
> going to work, and if you merely to probability checking (X% of all
> shots must hit), the level of tolerance you are going to have to put
> in to ensure you don't get drowned in false positives is going to
> let your cheating players get away with blue murder.

Right. And that would irritate players to no end. I have not played Diabl=
o
personally, but multiplayer Interstate '76 really pissed me off
(especially when a guy named Mr. Nice came along with his invulnerable ca=
r
and just toyed with 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.)
>=20
> Do a quick web search on the various hacks to the UOL protocols.
> Its been ugly.

I guess so. What can you do to protect yourself against this?

> > So ATM I am seriously thinking about proposing a client-server
> > architecture instead of peer-to-peer. I now need justification for
> > this decision.=20
>=20
> Without concentrator points (either central server or hubs
> (distributed server or IO-collection points feeding a central
> server)) peer-to-peer doesn't scale for low-latency tasks.

Right. That's one. :)

> Client/server doesn't scale where clients are able to exceed the sum
> IO or CPU bandwidth of the server. =20

Yes, but the solution is to buy a bigger and better server, right (as
opposed to upping the client system requirements another notch)? It's the
IO bandwidth (both in terms of network bandwidth and the IO throughput of
the computer) which bothers me somewhat. Some MMPOG games (such as
Middle-Earth On-Line, I think, as well as the Awakening Project)  promise
in excess of ten thousand clients connected at the same time.

> Peer models, by their very nature, assume a level of trust among
> peers.  That assumption is explicitly false when dealing with the Open
> Internet.  Peer models assume that individual nodes have good
> connectivity (latency and bandwidth proportional to the task), and
> that a node is responsbile for their own connection characteristics
> (latency and bandwidth). Both aspects are false on the Open Internet
> due to intervening connection characteristics (eg router between X and
> Y goes down) or lack of local 'net control (Denial of Service attack
> against node or subnet (a not uncommon tactic with some UOL players is
> for a player on a fast connection to swamp a player on a slow
> connection's link with large ping packets (eg 64K pings), rendering
> that player's character easy prey (they can't run, they can't fight,
> they can't hide)).=20

I guess that if the clients are unaware of the IP:s of other clients, it
is easier to avoid these kinds of denial of service attacks, right? (And,
above all, disable 'show IP' on your ICQ, too.) This is addressed
automatically in a client-server setup, whereas a peer-to-peer
architecture requires the clients to know the IP of each other.

> > 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.=20
>=20
> The above do?

They certainly do. Thanks a lot.

> > Some sample questions:
> >  - Is it a sound decision (using client-server)? =20
>=20
> Yes.

Glad to hear it.

> > - Can peer-to-peer be implemented without a lot of hassle with
> > authentication and so on? How? =20
>=20
> Yes.  There are standard libraries and protocols for this sort of
> thing.  (SSH and Kereberos come to mind)

Right.

> > - Is it possible in an Open Source project where anyone has access
> > to the source?=20
>=20
> Peer to peer?  No, due to trusted information paradoxes.

Okay.

> Client/server?  Yes, as the server can retain final arbiter status
> for critical points.

Indeed. Does anyone have an URL to a page describing the protocol of
multiplayer games such as Quake? It would certainly be useful to see the
granularity of messages these games uphold -- first-person shooters are b=
y
nature fast-paced and (I imagine) require a lot of information passed
between clients and server. Also, it would be useful to know what tasks
(if any) besides IO and rendering which are trusted to the client. Seeing
the failure of Diablo and I76 in these areas, I am inclined to believe
that very little trust is put into the client. Is this the case also with
Ultima Online?

[ snip guiding rule and NTP example ]

[ snip unscalable peer-to-peer model ]

> The tricky bit is ensuring that Y cannot guess the originator and
> likely characteristic of the event type to be arbitrated, and thus
> cannot provide usefully doctored information to Z:
>=20
>   "Oh yes, Z is requesting my state data.  That must be because X
> shot another bullet at me, so I'll report that I'm oriented so that
> my minimum profile is presented to X and that my shields just
> flashed on."
>=20
> This is why the request to Y doesn't come from X. but instead comes
> from Z, effectively attempting to make the source of the event
> anonymous with respect to Y.

Yes, this does seem a little bit hairy. Client-server has a *lot* more
appeal.

> > - Are there any large-scale multiplayer games (MMPOG, I believe
> > they are called) which uses a peer-to-peer architecture?
>=20
> Not that I know of.

A DIS company called M=E4k Technologies (<URL: http://www.mak.com>) just
released their own DIS/IVIS-based game called Spearhead (it's a tank game=
,
and it's not particularly popular with reviewers). I don't know any
details, but the multiplayer mode *should* have a peer-to-peer
architecture if it is using a DIS architecture.=20

> > - How would you keep the "distributed" in DIS with a client-server
> > architecture? =20
>=20
> Intelligent clients -- push all the computational load you can onto
> the client and then implement hairy trust models for your
> client/server relationships.

Sounds like a good mission statement.=20

> J C Lawrence                               Internet: claw at kanga.nu

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