Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a PeerCache using bootstraptribler.txt #81

Closed
NielsZeilemaker opened this issue Jul 5, 2013 · 1 comment
Closed

Create a PeerCache using bootstraptribler.txt #81

NielsZeilemaker opened this issue Jul 5, 2013 · 1 comment
Labels

Comments

@NielsZeilemaker
Copy link
Contributor

I was planning to add a peercache to Dispersy. Looking at the code, the bootstraptribler.txt file seemed like a logical choice to start with.

I'm planning to add another column, which determines if we should or should not sync with a peer. For our normal bootstrappeers, it would turn sync off and for all cached peers sync would be turned on.

By modifying get_bootstrap_candidates() in bootstrap.py, I could make it return either a BootstrapCandidate or a normal Candidates depending on the sync on/off.

Most of the other code would still work, as the 1% probability of selecting a bootstrap/peercache peer should be fine, and the create_introduction_request turns off sync depending on the instance-type of the candidate, i.e. whenever it gets a BootstrapCandidate.

However, I'm a bit concerned about the

assert all(not sock_address in self._candidates for sock_address in self._dispersy._bootstrap_candidates.iterkeys()), "none of the bootstrap candidates may be in self._candidates"

lines i'm seeing in the code. These will definitely cause problems.
I get why these were added, however is it possible to remove them from the get_candidate iterators etc? I guess we should only check this assert whenever we add a new candidate to the _candidates right?

@boudewijn-tribler
Copy link
Contributor

Perhaps it is cleaner to have all Candidate instances in one dictionary, i.e. remove self._bootstrap_candidates entirely, since the difference between the two is becoming less distinct. When we need a candidate we can just iterate over self._candidates and select any candidates that apply. This would also obsolete the assertion you mention.

I am a bit concerned about the trackers. Trackers should not walk towards each other, but should they walk towards these new Candidates?

Also, how should these new peers run? Tribler, tracker.py, or something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants