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

Should only auto(re)connect to peers we have a channel or some other business with #424

Open
delbonis opened this issue Oct 17, 2018 · 2 comments
Labels
low prio Nonessential changes that immedate concerns refactoring Significant changes to existing code to improve robustness/performance

Comments

@delbonis
Copy link
Collaborator

Because right now we try to connect to every peer we've ever known about, including Lit-AF instances that aren't listening and don't exist anymore.

This would probably involve a lot of changing how we load/track channels, so maybe worry about this then.

@delbonis delbonis added low prio Nonessential changes that immedate concerns refactoring Significant changes to existing code to improve robustness/performance labels Oct 17, 2018
@Varunram
Copy link
Contributor

Varunram commented Nov 8, 2018

Maybe we could have some kind of activity bool, (only) on trigger of which we store the peer in the db.

@delbonis
Copy link
Collaborator Author

delbonis commented Nov 8, 2018

I was thinking have separate tables/collections/buckets/whatever for "peers we know about" and "peers we actively should connect to". And the former of which we can use to drive the DHT when we get around to that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low prio Nonessential changes that immedate concerns refactoring Significant changes to existing code to improve robustness/performance
Projects
None yet
Development

No branches or pull requests

2 participants