DHT with computers

Hello everyone,

I want to build a system without central intelligence. That means that any central data must be stored on multiple (maybe every) computer which can be queries like a DHT and synchronizes between the peers. Does anyone have experience with such an approach?

Thanks in advance,
Guido.

Given that computers in CC are not limited by computing power or memory so you can just have the entire table on each system with some minimal synchronization code between them. As in literally just have a piece of code that runs every time you modify the table that sends a broadcast with the changes to every computer on the net. I am curious as to your motivation for such a thing though.

I'm coding a scenario where I spawn a turtle with a crafting table, tool, some coal and a tree seed, and want it to build the eiffeltower. So it needs to set up a forest, storage, etc. Create more turtles.

Whenever one turtle won't react, it would be nice if the system kept working. Especially during debug it happens a lot that a computer crashes.

So I want to be the system a bit more fail safe, and have data on more then one place. I just need to synchronize (easy part) and anticipate when two computers access the same data at the same time before the data was synchronized (hard part).

CC computers are not really working in parallel (usually, CC:T changes this I believe). That should simplify things for you.

Even if they don't work in parallel each change has to be broadcast to every other computer. And there is no guarantee that minecraft is going to neatly run the entire program of one computer before advancing to do the entire program of another. As evidenced by the fact we can and do write while true do loop UIs. So theoretically a computer might get to the state where it's changing values in after another has changed its but before it got to do the broadcast. Furthermore he has to contend with the possibility that some computers are going to crash (from the rest of his code) or not receive signals properly due to chunk loading issues. And thus they can end up with incorrect table versions. So a degree of redundancy is still important. But that can easily be solved by something as simple as a timestamp. As in:

1. Every time you want to change a table broadcast a signal saying "I want to change the table".
2. Every other computer receiving that signal responds back with the version number of the table it has. (5 changes = version 5, 50 changes = version 50)
4. Your computer checks these incoming versions and looks for the highest one. It than requests a download for that highest version from the PC that sent it. That way you know you have the latest possible version at any given time.
5. Once that is complete you can make your changes safely, increment the version number and broadcast them to the entire network who will than override their own with it.

Whilst all this is going on, as in between sending signal #2 and receiving #5 all your computers pause and refuse to make any changes of their own.

======================================================
So for example say you have Computers A, B, C and D.
A, B and C are all set to version 1. As in they haven't made any changes. D has made changes but was in an unloaded chunk or something like that so those changes newer got sent to the other 3. A now wants to make a change.

A: "I want to change the table."
B: 1
B: pauses
C: 1
C: pauses
D: 2
D: pauses

A: 2 > 1
A: Hey D! Give me your table.
D: sends table to A.
A: overrides local table with what she got from D.
A: changes table.
A: sets table number to 3.
A: sends table to everyone.

B, C and D all receive table, override their own with it and unpause.

======================================================
Now this process is not foolproof in that he still can end up in a mismatch situation should the computer holding the currently highest table be in an unloaded chunk and that happened just before it got to broadcast its changes. But that's a really low probability all in all.

Interesting approach, thank you. I'll add a version number to the data so at least I can detect a possible conflict. The detection of a conflict is easy to code. Not sure what to do when a difference is detected though. I think implementing a full dht like bitcoin or the torrent peer network uses is too complicated for my use.

Just adding a version number without the sort of checkout system I described won't work. What happens if both A and B are on version 1 and both make changes? You now have two different versions 2. You really do need to actually have the sort of synchronization I mentioned. But on the plus side that's trivially easy to incorporate into your code assuming you already have a while true do loop.