[DGD] DGD and *dbm

[Shentino]

This sort of problem is EXACTLY why I suggested a plug-in interface
that would allow an extension module to play nicely with
multithreading and still add functionality.

Define your own extensions, and supply hooks to tell DGD/MP if you can
commit, if you are aborted, etc, etc, and simply let the extension
deal with MP's belly-aching about rescheduling and commitment.  MP's
own mechanisms would be hard coded in this respect, and for an
extension, some hooks could properly tell MP how to handle threads.
If an asynchronous event happens, the extension requests an exec round
in much the same way as MP would do so on it's own stuff (incoming
connections, the interrupt signal, etc).

I maintain that it can almost certainly be backwards compatible with
vanilla DGD simply by making it a degenerate case of MP wherein there
is only one processor.

An extension would code to the MP interface (which would be internally
dummied down a ways for SP), and work on both SP and MP at the source
level.

Such an interface would support the following:

gdbm
   thread start: lock the db?
   rollback: cancel everything
   commit: write everything
networking
   thread start: nothing
   rollback: forget we were ever asked
   commit: actually do our sends and stuff.
SQL
   thread start: BEGIN TRANSACTION
   rollback: ABORT TRANSACTION
   commit: CLOSE TRANSACTION
  (syntax may be off a bit)

I'd still need to take a look at the MP code to see how correct my
hypothesis is, of course. :P.

And to felix (about named pipes and blah):

Using the filesystem with named sockets and pipes is the only way I
know how to properly secure the "networking package" from tampering by
other users who may happen to be sharing a server.  Like
necronomicorp, for instance.

Writing a daemon to utilize DGD's existing I/O interface is fraught
with race conditions.  It's easy to ensure security if you're the only
one using the box.  I would probably have better luck doing this if
DGD's architecture continues to move in an fs and net-out hostile
direction, however, races and security continue to give me concern.

For one, how do you reliably distinguish an incoming connection as one
sent by the network daemon, versus one that comes in from a regular
user (who, btw, could easily be another user on the same server, hence
an IP of 127.0.0.1, or it could even be the admin testing the mud
out), or worse, a rogue attempting to masquerade as the networking
daemon (or for that matter, a logging daemon, or anything else outside
the DGD process that communicates with same through a socket)?  Having
a dedicated port reserved exclusively for the LPC side network
handling would still leave a port exposed to other users on your
server even if the config file forbids server-external connections.
Even restricting it to localhost only would still not immunize my code
from rogue connections trying to masquerade as a networking daemon,
and given the current trend, I seriously doubt that DGD of any sort
would be utilizing identd services...

Using a filesystem's access control mechanisms to secure the "I/O
directory" is much simpler.

And yes, having a dedicated server is the best way to handle it (then
you could keep everything sealed up).  Unfortunately for us hobbyist
types, using a dedicated server of any sort is either a pain in the
rear, an exercise in genius, or a bite out of the pocket book.  Or any
two or even all three of the above.

On Mon, Jul 21, 2008 at 3:08 PM,  <bart at wotf.org> wrote:
> On Mon, 21 Jul 2008 23:40:46 +0200, Felix A. Croes wrote
>> bart at wotf.org wrote:
>>
>> >[...]
>> > And that brings me back to the original subject of this thread, and makes me
>> > curious about DGD/MP with a dbm that supports nested atomic transactions. It
>> > would provide a way to deal with rollback and somewhat efficient disk storage
>> > for data that you don't want to keep inside the mud. Hmmmmm.. when can I get
>> > my hands dirty with that, Felix? :)
>>
>> See my previous message.  And rather than giving an E.T.A., let me
>> say that I still have to refine the architecture of DGD/MP in ways
>> that make such hacks as the above less and less feasible before I
>> am ready to release the code.
>
> CRY!
>
> Ah well, guess I have to live with it, for now sp is where my playground is
> anyway, and enough to do there.
>
> Wrt your previous message, it has to involve changing DGD's commit/rollback to
> deal with database objects indeed. Obviously, I have no idea how difficult
> that is going to be for DGD/MP, but you don't make it sound good.. but then..
> thats usualy the case with what I want to do (and it seldom stops me) :)
>
> Bart.
> --
> Created with Open WebMail at http://www.bartsplace.net/
> Read my weblog at http://soapbox.bartsplace.net/
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>