Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Storing and restoring entries #3

Closed
jure opened this Issue · 3 comments

2 participants

@jure

Right now, my nodes will remember their peer Id and rejoin the network with the same peer Id at any point in the future. I would also like them to regain the entries that they had before leaving the network.

I'm thinking of doing something like this:

chord.onentriesinserted = _.debounce(function() {
    console.log('Storing entries locally.');
    var entries = _.map(chord._localNode._entries._entries, function (entry) {
        entry.toJson();
    });
    chrome.storage.local.set({entries: entries});
}, 10000);

and then something like:

chrome.storage.local.get('entries', function (obj) {
    if(obj.entries !== undefined) {
        _.each(obj.entries, function(entry) {
            chord._localNode._entries.add(Entry.fromJson(entry));
        });
    }
});

Would this work, do you think there is a better, idiomatic way to do this? What happens if I rejoin the network and one of my entry's items are different (there fewer or more) than what is currently on the network for this entry?

@tsujio
Owner

In webrtc-chord the node ID of a node is the sha256 hash of the peer ID, so nodes which have the same peer ID also have the same node ID. If you rejoin with the same peer ID, you are assigned the same responsibility range of storing entries.
And inserted entries are replicated into the successors, so when you rejoin with the same peer ID, the entries which you previous had are re-assigned to you.

However, if there is no peer in the network excluding you, the entries disappear on your leaving.
I will add 'getEntries' API to Chord class in order to remember the entries.

# In my js coding style, properties starts with '_' are private properties.

@jure jure referenced this issue from a commit
tsujio Add get/setEntries API to Chord class a196c4f
@jure

Thanks for adding those get and setEntries APIs and for your explanation of the effects of keeping the same peer ID. I'll close this issue.

I still have one question about the entries restoring, imagine this situation:
1. Peer 1 creates a network
2. Peer 2 joins this network
3. Peer 2 adds 1 to its entries for "key" and it now holds "key": [1]
4. This entry is replicated to Peer 1
5. Peer 2 leaves network
6. Peer 1 is now in control of "key": [1]
7. Peer 1 adds 2 to its entries for "key" and it now holds "key": [1,2]
8. Peer 2 now rejoins the network and restores its entries from local storage, so it now has "key": [1]
9 . At this point Peer 1 has "key": [1,2] and Peer 2 has "key": [1]. What happens now? Is it deterministic?

@jure jure closed this
@tsujio
Owner

In that case, when Peer 2 join the network it fetches entries which Peer 2 is in charge of from its successor (Peer 1).

In webrtc-chord the id of an entry is also sha256 hash of the key of the entry.
So what peer retains what entry is decided as the following.

if sha256(Peer 1's peer id) < sha256(entry's key) <= sha256(Peer 2's peer id), then
  Peer 2 retains the entry.
else if sha256(Peer 2's peer id) < sha256(entry's key) <= sha256(Peer 1's peer id), then
  Peer 1 retains the entry.

# As you know, chord network is ring.

But as I had mentioned above, entries are replicated into successors, so if there are only two peers, both Peer 1 and Peer 2 finally retain "key": [1,2].
# If it does not perform as so, some bugs may exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.