[Prev][Next][Index][Thread]

# Re: turning player_db and match_player into builtins..

- Date: Sat, 21 Sep 1996 13:16:30 -0600 (MDT)
- From:
- Cc: Sergio Costa <i940537@chico.idt-isep.ipp.pt>, moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <Pine.SUN.3.93.960920213344.21909E-100000@xs1.xs4all.nl>

    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:

- Re: turning player_db and match_player into builtins..

- From: <thomas@xs4all.nl>

- Prev: Re: turning player_db and match_player into builtins..
- Next: Re: turning player_db and match_player into builtins..
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index