March 1998
- Describe Concept Stephen Zepp
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Vadim Tkachenko
- Tutorial: Let's build a Compiler! - Part XI: Lexical Scan Revisited Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XII: Miscellany Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XIII: Procedures Jon A. Lambert
- Tutorial: Let's build a Compiler! Chris Gray
- VEIL Network Protocol Brandon Gillespie
- Tutorial: Let's build a Compiler! - Part XIV: Types Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XV: Back to the Future Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XVI: Unit Construction Jon A. Lambert
- For Ling's FAQ Koster, Raph
- MUD Ratings jlsysinc.ix.netcom.com@ix.netcom.com
- Random Generation Tools Ling
- ANNOUNCE: DB Robin Carey
- THE DARKWHOLE TESTS J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor Jon A. Lambert
- Magic as Metaphor J C Lawrence
- CT - A Hypothetical Session (mid 1995) J C Lawrence
- 2Cyberconf: An article J C Lawrence
- (long) AnarchyMOO Primary Log J C Lawrence
- (short) AnarchyMOO parting salute J C Lawrence
- AnarchyMOO purpose J C Lawrence
- (fwd) CODE RELEASE: [client] Spod! (Java mud client) J C Lawrence
- (fwd) CODE RELEASE: [client]: lyntin (hacker's client) 1.1b Released J C Lawrence
- DarkWhole Test #1 J C Lawrence
- DarkWhole Test #2 J C Lawrence
- DarkWhole test #3 J C Lawrence
- DarkWhole test #4 J C Lawrence
- DarkWhole test #5 J C Lawrence
- DarkWhole test Identity Crisis J C Lawrence
- The Craft of Adventure J C Lawrence
- What in THE Hell was that? Stephen Zepp
- What in THE Hell was that? Ben Greear
- What in THE Hell was that? J C Lawrence
- What in THE Hell was that? Jon A. Lambert
- (fwd) Varying Time Commitment Levels: what's an admin to do? J C Lawrence
- Hello, and a brief intro cimri
- Hello, and a brief intro Ben Greear
- (no title) Time limits? s001gmu@nova.wright.edu
- (no title) Time limits? Justin McKinnerney
- (no title) Time limits? J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Re: Vadim Tkachenko
- META: Broken mail headers coder@ibm.net
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Chris Gray
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Caliban Tiresias Darklock
- META: Broken mail headers Chris Gray
- Turn-based MU*'s Sauron
- Balancing Addicts -> soft vs. hard enforcement cimri
- Balancing Addicts -> soft vs. hard enforcement Justin McKinnerney
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Ling
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement Adam Wiggins
- Balancing Addicts -> soft vs. hard enforcement Joel Dillon
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Jon A. Lambert
- SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Chris Gray
- SfD: Clientside Caching Jon A. Lambert
- (subject missing) J C Lawrence
- Balancing Addicts Ling
- Balancing Addicts Richard Woolcock
- Balancing Addicts Ling
- Balancing Addicts J C Lawrence
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Chris Gray
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon A. Lambert
- Transport layer (UDP vs TCP) Ben Greear
- Time Limits? Jon A. Lambert
- META: topic and thread culling (was Balancing Addicts -> soft vs. hard enforcement ) J C Lawrence
- (subject missing) J C Lawrence
- XShipWars J C Lawrence
- (fwd) INFO: [client] Chaco looking for new parent for Pueblo J C Lawrence
- SIMULATING FUTURE HISTORIES: THE NAU SOLAR SYSTEM SIMULATION & MARS SETTLEMENT J C Lawrence
- (fwd) Functional Security J C Lawrence
- (fwd) Functional Security Ling
- (fwd) Functional Security Chris Gray
- (fwd) Functional Security Matt Chatterley
- (fwd) Functional Security Miroslav Silovic
- (fwd) Functional Security Felix A. Croes
- (fwd) Functional Security J C Lawrence
- SIMULATING FUTURE HISTORIES s001gmu@nova.wright.edu
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis Casey
- Character development [was ] J C Lawrence
- Character development [was ] Travis S. Casey
- Character development [was ] Marian Griffith
- Character development [was ] Travis S. Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Marian Griffith
- Character development [was ] J C Lawrence
- Character development [was ] Cimri
- Character development [was ] J C Lawrence
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Vadim Tkachenko
- Character development [was ] Ben Greear
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis S. Casey
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] Alex Bertoglio
- Character development [was ] J C Lawrence
- Character development [was ] J C Lawrence
- Character development [was ] John Bertoglio
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs J C Lawrence
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs Ling
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Mike Sellers
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Ling
- 3D engines for MUDs s001gmu@nova.wright.edu
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Greg Munt
- Dynamic Loading of Modules J C Lawrence
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Vadim Tkachenko
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Chris Gray
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Nathan F Yospe
- Parlez vous NPC? Matt Chatterley
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Chris Gray
- Dynamic Loading of Modules Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
On Tue, 24 Mar 1998 21:42:41 PST8PDT
Vadim Tkachenko<vt@freehold.crocodile.org> wrote:
> Chris Gray wrote:
>> [Vadim Tkachenko:]
>> Some potential problems:
>>
>> - if multiple threads are updating the single image of the DB
>> (whether those threads are local or remote), then you need some
>> kind of consistency mechanism. If you use locks, then you are
>> vulnerable to a client vanishing when it holds locks - you will
>> have to detect that and rip the locks away.
> Sure, that's why there is a concept of a business logic - client
> doesn't hold any locks at all. Everything is split into
> transactions, and any possible locks are handled by the business
> logic.
Most (I'm pretty sure all but one?) transaction models require locks.
If you don't take the roll-back approach I use, then then you are
going to have locks, no matter how you try and wrap or re-phrase it.
> When the client dies, there are two possibilities - one, it drops
> the connection, which automatically leads to the IOException and
> depending on the higher-level protocol handling it's either
> disconnected or put into the linkdead state. Two, it lags out, which
> is worse but can be handled somehow - any comments on this case?
Given that TCP/IP has no concept of link state maintenance (at least
not in the same way as the SNA world where you'll know within 3ms if
the other end goes way or if anything at _ALL_ happens to the
connection), this makes for a latency problem: How to tell if the
other end is just being slow, or has gone away? Do you postpone later
dependant transactions until you have determined the state of the
connection (expensive if by timeout) or do you just proceed willy
nilly and attempt to figure out how to recover if it then turns out
that the other end really did go away (logical dependency nightmare).
>> This also means that your execution model has to be very complete
>> with respect to locks,
> Always :-)
Then again, you can always use a lockless model, which has other
expenses, and tends to require a lot more rigour in your world design.
>> With remotely held locks, you can get some *very* large latencies.
> Never have the remotely held locks, then :-)
Okay. How?
>> Alternatively, you might try Chris L's lockless scheme, or some
>> variant.
> What is that? Can you give me a reference, please?
Its not original to me. I copied it in turn from Demo's DOME project
(http://autos.cs.tu-berlin.de/~demos/dome.html). The basic model is
well known in the DB world, and has been hashed and rehashed here many
many times.
LING: Demo's DOME project should be in the FAQ, as should the
description of the lockless model, and the dragon's dinner scenario
quoted below should be inserted into the definitions part of the FAQ
whole cloth.
-<cut>-
A Lockless Server or DB design
------------------------------
Events request objects from the DB.
If the object is not in the cache, the DB loads the object.
The DB replies to the event with a read-only shared reference to the
object.
The event is added to the "interested parties" list for the object.
If the event attempts to modify the object, a new local,
event-specific copy of the object is made, and the changes are made to
that. A copy of the original reference however is still kept.
The event (loosely) attempts to keep track of what members of the
object it referenced.
During the execution of an event. all external IO is buffered and held.
Upon the event terminating it compares its copy of the original object
(the local reference) with the object that's actually in the DB (may
have been changed by events commiting during the current event's
execution). Some intelligence is attempted here to only compare those
values etc which were referenced by the event.
Should the original copy and the current-in-DB copy compare OK, then
the event commits, the IO is released, and all its changes in its
written-to copies are commited atomically. This is the
Compare&Commit, or C&C.
If the C&C fails, the event is thrown away, all the copies are
released, the IO is discarded, and the event is rescheduled to try
again.
There is also some background intelligence here where the DB watches
the objects that are affected by event's C&C'ing, and will signal the
other events that are members of those object's interested party list
that they may be invalidated by the other event's C&C and so should
kill themselves and reschedule.
-<cut>-
Background data:
-<cut>-
/(o__. _____| \ |OcO|
---------/|-/|-( ,__)-------| | |--------+++++++++/|_| - |_ -----------
/\/ |/ |/ _ \++++++C+O+M+P+L|E+X+I+T+Y+++++O+F+++/f| `-' |
|\/ / \/ "++++++D+|+S+T+R+I+B+U+T+E+D+( u| |
___| . .____. /______________| "|++++++S+Y+S+T+E+M+S+\n|_)___(_/-----------
_| /| |_ || |_ |____| | "++++++++\| | | | \
/__/LL__,) LL__,) | / (__|__) \
Pretty picture depicting the famous `` Dragon's Dinner'' problem, by
Jutta Degener.
The Dragon's dinner problem
---------------------------
One of the original goals for the DOME project was to provide a
parallel/distributed execution envirionment for an LPmud game
driver. LPmud is programmed in a langauge called LPC, which is derived
from C and enriched with constructs to enable object oriented
programming, complex data types such as associative arrays and lambda
closures. This is interpreted by the game driver which provides single
threaded execution semantics. Items in the game are represented by
LPC objects which provide methods specifiying how they interact with
other objects in the game.
Consider the following problem (dubbed "Dragon's Dinner"). Assume, in
an asynchronous distributed system, that there are two room objects
(r1, r2) and a door object (d) that connects them. R1 contains a
hungry dragon (hd) and r2 contains an adventurer (a). The door is
currently open, the adventurer has just fled from r1 and is about to
close the door. The dragon, on the other hand, wants to go after the
adventurer. Code for the dragon is something like:
if (d->is_open())
hd->move_to(r2);
And the code for closing the door is something like:
d->close();
Now what if the following happens: The thread that executes the
dragon's action has checked that the door is indeed open, while the
other thread which is concurrently executing on a different processor,
closes the door. This succeeds and the adventurer sees the door
closing. However, when control returns to the dragon's thread, it
still believes that the door is open and steps through it, much to the
surprise of the adventurer who sees the dragon walking through a
closed door, before being devoured by the dragon.
Naturally this is merely a race-condition dictated by the asynchronous
execution of two data-dependent threads. The main goal of the DOME
project is to provide a system where the component objects can be
programmed in a sequential fashion, but have the run-time support
resolve such race-conditions (in a deadlock free manner) so that
parallel execution can be achieved.
Alexander Weidt [June 1995]
-<cut>-
<sigh> Once I get the web archives up, we'll be quoting URL's here
instead of text blob's, or more likely pithy statements to the effect
of, "Read The F'ing Archives on XXX!". I'm not sure if that's a good
thing tho. It does increase signal, but removes context from readers
unfamiliar with the prior traffic (ie it requires significantly more
work of them to maintain context). Hurm. Methinks I prefer text over
external references.
>> In either case, information generated by a thread run often
>> produces output that must go to several clients. Does each client
>> know about all other clients, and so can send directly, or does
>> that information have to bounce through the server?
> I'd probably have a special kind of 'broadcast handler' business
> logic (BL) to do that (as I mentioned before, the BL adaptors are
> stackable, and there may be three ways of handling the request by
> the BL adaptor:
Note that your handling of IO is heavily dependant on your
transactional model. No matter what model you adapt however, you
*CAN'T* deliver IO from a transaction until after that transaction
commits. After all, you can't rollback IO...
>> - threads often need a fair amount of context (mostly read-only) to
>> run. Getting the up-to-date version of that to the clients can up
>> your latency quite a bit. You can cache information like that on
>> the clients, but see recent discussion on that for some hazards.
> Can't answer this yet, the first thought is that I try to follow the
> MVC paradigm, and everything on the other end of the connection is
> either V or C for me, so all the data you're talking about here will
> probably end up in the BLs on the server side.
The MVC model assumes a high bandwidth connection between M, V, and C.
Yes, this can be worked around. No, I don't think its worth it as you
end up working extremely hard in order to preserve a model which is
not suited (at that purity level) for the application. its much
easier to put cacheing and other state concepts into each layer (M, V,
and C) in order to minimise the bandwidth requirements of
synchronising the data transfers between them.
--
J C Lawrence Internet: claw@null.net
(Contractor) Internet: coder@ibm.net
---------(*) Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Adam Wiggins
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Orion Henry
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Nathan F Yospe
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- Jukebox Vadim Tkachenko
- Another recruit for the list? Joel Dillon
- OT: Martin Keegan J C Lawrence
- Old code Joel Dillon
- Old code Michael Hohensee
- UML/Commercial v Free Muds Greg Munt
- UML/Commercial v Free Muds Nathan F Yospe
- UML/Commercial v Free Muds Jon A. Lambert
- Heightfield Terrain Rendering Paper Niklas Elmqvist
- (subject missing) J C Lawrence
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying s001gmu@nova.wright.edu
- (fwd) Roleplaying Katrina McClelan
- (fwd) Roleplaying Ling
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying Travis Casey
- Predicting future motion intelligently J C Lawrence
- META: New Mail server and ISP J C Lawrence
- (rec.games.mud.admin) Roleplaying (fwd) Nathan F Yospe
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Jon A. Lambert
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- UML & CORBA Greg Munt
- [MUD-Dev]: smoothing J C Lawrence
- [MUD-Dev]: smoothing J C Lawrence