[DGD] Kotaka + DGD flexibility and performance?

[Raymond Jennings]

On Sun, Dec 9, 2018 at 4:00 AM <bart at wotf.org> wrote:

> I have been putting a fair bit of thought into such a distributed system,
> and
> within some constraints I think it can be made to work well.
>
> The constraints mostly concern guaranteeing consistency between instances,
> and
> making sure important transactions are atomic, ie a move between 2 areas
> which
> are handled by different instances should still be atomic.
>

I have two levels of consistency in mind.  Both inspired by Geir (Gier?)
Hansen's project

First, transactional.  In this case the universe is partitioned by
containment, and any object can be the "head object" of a particular
instance.  That object, along with all objects it contains, are "owned" by
the instance in question, unless an object down below has been "delegated"
to a subordinate node.

An object's inventory and environment would be properties of that object
and handled the same as any other.  My guess is that during the transition,
the object would be duplicated, but only one of the objects would be
considered "official".  For a loose analogy, look at the MESI cache
coherency protocol used by Intel CPUs.  My guess is that objects at or near
an instance border would be shadowed or cached so to speak, granting read
access to adjacent instances, but only the instance which actually owns it
would be granted write access.

Additionally, I plan to have speculative execution inspired by GH's project
and not unlike how DGD itself handles thread rollback.  To be blunt, if two
"threads" wind up trying to get into a fight, one of them will be forced to
back off.

It's possible that the "write access baton" could be passed around as
needed.  My first guess is that the instance that owns the object would
grant an exclusive "write lease" for the object to another instance.

I haven't figured it out yet, but to avoid the "dragon's dinner" problem I
do plan to have some sort of mutual exclusion thing going on to keep two
tasks from screwing with the same object at the same time.

Game-wise, each object will have "initiative points" that are periodically
recharged.  So living objects won't be able to do game actions unless they
have the budget for it.

Objects moving between instances would probably involve reservations to
prevent interference.

Second is durability.

When it's time to take a data dump, all activity is quiesced and then
snapshots are dumped.  With the synchronization performed, this collection
of snapshots is guaranteed to be consistent.

There are known approaches for this, but all of those involve some
> compromises
> either on how fast you can handle transactions and/or how much consistency
> you
> can guarantee, and always to what level you can guarantee consistency.
>
> Put differently, offloading responsibility for data to another instance is
> not
> much different from putting data in a database. As soon as your data is
> external to the current dgd instance, you cannot properly guarantee
> modifications are atomic to the same level as atomic functions in dgd can
> with
> regards to data that is internal to dgd.
>

All this would do is add a layer of abstraction on top.  Game code would
probably go through an API of sorts and thus see the universe as a unified
whole.

But, if your 'world model' can live with this, it is quite workable I think.
>
> Bart.
>
> On Sat, 8 Dec 2018 15:24:48 -0800, Raymond Jennings wrote
> <snip>
>
> > In the future I plan to have it as the basis for a multi-node concurrent
> > distributed world inspired by the work of Geir Hansen.
> >
> --
> https://www.bartsplace.net/
> https://wotf.org/
> https://www.flickr.com/photos/mrobjective/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd