MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: turning player_db and match_player into builtins..



GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca 
YMCA Edmonton             
(Back on line!>

On Fri, 20 Sep 1996 thomas@xs4all.nl wrote:

> 
> 
> On Fri, 20 Sep 1996, Sergio Costa wrote:
> 
> >   I was just wondering if that was at all possible...
> >   I mean hacking the C code to include both things..
> 
> It's possible, of course (anythings possible on Unix, certainly with C ;)
> but i doubt it will be easy, bugfree, speedy, or smart. Main problem would
> seem to be the time usage. Certainly, it will be (lots ?) faster than the db
> one, but it will only take one tick. MOO itself isn't multitasking, merely
> taskswitching, so a large player_db in server and all accompanying
> functions, could create massive lag-spurts. Whereas verbs in-db can (and big
> ones must) call either suspend() or read(), which gives other threads a
> chance.
> 
> More bad things: how were you planning on putting it in the server ? you
> would need a lot of new functions, a few for the player_db, a few for the
> match... and you'd need a few more builtins. Maintaining a list like that in
> server also isn't a joke. you have to keep your pointers in check, your
> array bounds, etc. 
> 
> 
Sounds like time for a Bf-Wrapper..... :)

The Database already includes a very basic player database that consists
of a list of valid players.

(Anybody who attempts to hack the database directly learns this, because it
is the first thing in the database, even before the actual data for object
#0.)

What I hear here, is the need to ballance between the need for a single task
for the whole moo, and the need to design it to act as if it were a multiple
processing system so lots of people can join.

If the task is kept to one thread, or three, as it is already designed to be,
run as, then the depth of any function within the "SERVER" portion, must be
kept to a minimum, or you will get patchy performance, as some processes, 
take longer to complete, but take up the same number of "Ticks". The user
database, gets longer whenever another user gets added. Since it is really
implimented in much the same way as any other list, is, the cost of searching
for a specific object within the list, is increased with every added user.

This is what they call OVERHEAD, in server parliance, and is an unrecoverable
cost of using the Server to do the search. The more complex you make the 
list, such as including new information in each record, such as the name of
the player, and permissions etc, the longer it will take to respond even at
the server level. 

The first person was correct in saying that it would take less time, if 
it were done in the server, but the second was also correct in pointing out
that this time would affect the way the server was percieved to run.

Of course part of the problem, is that the server itself is using serial
lists to do everything. Knowing that hundreds or thousands of Users may 
want to be seen as "Valid" in the database, makes it likely that any serial
list oriented data engine is going to get locked up.

So whether it gets lagged because the server is lagging on the search, or 
whether it gets lagged because it is competing with other software for an
openning to run, makes little difference to the general operating of the
system it just slows down the practical access of the information.

One use for B+Tree, or even B-Tree or Treive technology, is that it speeds
the access to a database by allowing the database to be accessed utilizing
random access capabilities rather than using serial list capabilities. you
simply need a little overhead to handle the B+Tree, and you cut out the
length consideration to response. An even better alternative is the extended
Hashing functions that allow you to do away with most of the actual overhead
as well, but while I understand the requirements for the B+tree or treive
I don't necessarily understand the same requirements when extended hashing
is involved.

In a while, I will begin to work on Mod1 of newcore, in which I intend to
impliment a B+TREE technology as a "DATABASE in DB". I believe that this
technology, even implimented on the servers serial-list capabilities of
1.7.7 and 1.7.8p4 vintage will be a significant addition to the MOO base.

One of the reasons that I am building this base, below the user-level, is
to allow greater flexibility at the Userlevel, when I get there. In Mod0,
I created basic tourist objects that essentially were glued in place, simply
to allow people to "Look around" at the minimum architecture. In Mod1 I will
make it possible for there to be a more rich environment for them to move
around in, because the environment itself can be extended from a 
Database-inDB technology.

When I attempt to re-write the technology to move it to 1.8.0 level server
I will have to deal with all the system level junk that was added in 1.8.x
which will probably require a re-write of how I achieve the same effect but
may increase its real efficiency at the same time... Don't know because the
uses of trys and exceptions is still somewhat new to me. :)

If you want the ability to do "TABLES" or the ability to use B+TREES in the
server itself, I think you will have to accept that the overhead of the
server will be increased, at least in memory. And therefore the ultimate size
of your Database, will become more and more reliant on the swap space or 
FUP interface.


				GREY
References:
Home | Subject Index | Thread Index