November 1998
- ADMIN: Unsubscriptions J C Lawrence
- ScryMUD [CUSTOM] Code release. Ben Greear
- Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
- DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Adam J. Thornton
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article David Bennett
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Marc Hernandez
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Vadim Tkachenko
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Ola Fosheim Grøstad
- DevMUD considerations and the Halloween article Chris Gray
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Flamebite of the day Vadim Tkachenko
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
- META: DevMUD, MUD-Dev, and (list) futures James Wilson
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Niklas Elmqvist
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Thandor
- My vision for DevMUD Robert Woods
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Thandor
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Caliban Tiresias Darklock
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Darrin Hyrup
- My vision for DevMUD Jon Leonard
- My vision for DevMUD J C Lawrence
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Hal Black
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Chris Gray
- My vision for DevMUD Chris Gray
- My vision for DevMUD Ben Greear
- My vision for DevMUD Jo Dillon
- My vision for DevMUD Ben Greear
- DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Adam Wiggins
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Simon Duggan
- DevCore Project Management Jon Leonard
- DevCore Project Management Chris Gray
- DevCore Project Management Darrin Hyrup
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
- Drama Theory Ling
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Moral license (My vision for DevMUD) ApplePiMan@aol.com
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Fwd: My vision for DevMUD Jon Leonard
- DevMUD Prototyping Niklas Elmqvist
- Altima... Thandor
- Fwd: My vision for DevMUD Darrin Hyrup
- Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
- Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
- [DevMud] quick question... Franklyn Colebrooke, Jr.
- signal to noise... Andrew Wilson
- "knights and merchants" - NYTimes review James Wilson
- ADMIN: DevMUD posting authority promotions J C Lawrence
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Emil Eifrem
- A Small Conceptual Object System For MUDs Mark Gritter
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Jon A. Lambert
- Random Quest Generation chris@realm.zfn.uni-bremen.de
- Random Quest Generation Chris Gray
- Random Quest Generation Michael.Willey@abnamro.com
- Random Quest Generation J C Lawrence
- Random Quest Generation J C Lawrence
- Quick socket question Dr. Cat
- Quick socket question Jon Leonard
- Quick socket question Ben Greear
- Quick socket question Chris Gray
- Quick socket question J C Lawrence
- Quick socket question J C Lawrence
- Quick socket question Adam Wiggins
- Quick socket question Petri Virkkula
- ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
- Quick socket answer Dr. Cat
- Rebol Ling
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Adam Wiggins
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Ling
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Peck, Matthew x96724c1
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Adam J. Thornton
- Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
- Spell components, chemistry, and the like... Emil Eifrem
- Spell components, chemistry, and the like... Nathan F Yospe
- ADMIN: Attributions J C Lawrence
- AMIN: Unsubscriptions J C Lawrence
- OO Design Question Brad Leach
- OO Design Question J C Lawrence
- Chemistry [Warning, scientific content] Peck, Matthew x96724c1
- MUD clients, testing Chris Gray
- MUD clients, testing Scatter
- MUD clients, testing J C Lawrence
- JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
- More module ideas Mark Gritter
- The Innerworld Project Niklas Elmqvist
- META: FAQ's bios. Ling
- Mage 2 Mage 0.89 J C Lawrence
- Game library notes J C Lawrence
- World Building Page Ling
- ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Mik Clarke
- DIS: Client-Server vs Peer-to-Peer Adam Wiggins
- DIS: Client-Server vs Peer-to-Peer Jon Leonard
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- 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 - DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- Ruminations on CVS and developing in the Bazaar Ben Greear
- Ruminations on CVS and developing in the Bazaar Chris Gray
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar Petri Virkkula
- DevMUD: List data, subscription, and the rest J C Lawrence
- DevMUD: List data, subscription, and the rest J C Lawrence
- Atention SSH/Java-developers (MindTerm update) J C Lawrence
- ScryMUD/Hegemon code Release Ben Greear