[MUD-Dev] Persistant storage.... My current idea.

[Ben Greear]

On Fri, 3 Apr 1998, J C Lawrence wrote:

> Learn the lessons of Marcus Ranum and UnterMUD.  Diask-based servers
> can and do significantly out-perform in-RAM servers due to the lower
> rate of page faults -- despite the file IO overhead.  Of the current
> server architectures Cold is a perfect example in point.  cf Brandon's 
> and Miro's oft referenced performance figures for Cold.

Well, I'll give it a look if I get time.  I believe we both understand
the other's position, so I'll consider this one discussed :)

> Really?  Does this mean that objects migrate between servers?  Think
> this thru:

Yes, objects will migrate, probably through a 'gate' or some other
transport mechanism.  The servers will do handoff of IO as smoothly
as possible....

> 
>   Object A is defined on Server X.
> 
>   A inherits from objects Q, R, S, and T, also defined on X.
> 
>   You now move A to server Y.
> 
>   Do Q, R, S and T, __and__ all their other children follow?
> 
>   What about all the objects that remain on X that inherit from those
> objects too?

Ummm, not sure I understand this.  It makes no sense to me.  My idea is
thus:  You have a space ship, with cargo, and various objects on board.
You go through a 'gate' to another server (solar system).  Every object
within the ship leaves the previous one and joins the latter.  The
java classes of course do not move, and in fact are found on ever server.

 
> 
>   Do you merely make copies of A, Q, R, S, and T, on Y, and leave the
> originals on X?

No copies, in this world there is only one of everything (as in RL).

> Please, have a good long look at COOL, and realise its strengths and
> weaknesses.  COOL's model is expensive on net traffic, but objects tay
> where they are defined, allowing their contexts to be known and well
> defined.  All object calls are then RPC's across the net.  

I have to be very careful of net traffic, I want to be able to do full
motion, real-time'ish GUI displays, the more updates I can pump through,
the more in sync the clients will be, and thus the better the response
time the user will see.

> 
> This is not to say that moving the objects is automatically a bad
> idea.  It has significant benefits over RPC'ing everythinbg -- it just
> also requires significantly more engineeing effort to maintain logical
> consistency.

Think of a player moving from one room to another in a MUD, then scale it
up a bit, that is what I'm thinking of...

> > I'm just going to put them on the end.  I'd wrather waste disk space
> > than take the time to be clever.  Besides, as the objects' images on
> > the disk will change, I'll need some room to grow and shrink w/out
> > affecting the neighbors.
> 
> Why?  If you use the suggested model there is very little overhead to
> finding a free location for an object (when I did this I merely
> maintained a free block list for a total expense of perhaps 20 LOC).
> There is also no concern with object size changes:

I'll give that through as well...  first pass gonna be simple and stupid
though :)

> ADSL has not quite reached my part of the SF Bay area (its close), but
> that's $180 for 384Kbps symmetrical (it varies slightly depending on
> who you pick for your CLEC: PacBell, Covad, or NorthPoint).  IDSL
> (which I'd be more likely to go for), has yet to establish a firm
> pricing model here alas.

Here in phoenix:  around $40 a month for a cable modem, around 1 Mbps
average it seems..both ways!

ADSL:  $60 a month, including renting the modem and internet access,
256Kbps both ways...can get 512Kbps for about $85 a month I think...


Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444
http://www.primenet.com/~greear/ScryMUD/scry.html