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

GraceLimit #259

Closed
Winterhuman opened this issue Jan 2, 2022 · 6 comments
Closed

GraceLimit #259

Winterhuman opened this issue Jan 2, 2022 · 6 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@Winterhuman
Copy link

Right now, connections can quickly build up when initially starting an IPFS node (ipfs/kubo#3065, and many other similar issues here). So, I propose introducing a new option called GraceLimit.

GraceLimit

GracePeriod enforces the low and high water levels only when X amount of time has passed. During this time many connection are able to be opened which is most likely the cause of multiple router crashing issues; GracePeriod isn't strict enough. Instead, GraceLimit enforces the low and high water levels using all the same rules as GracePeriod except that instead of time it uses the number of connections.

This is a much stricter means of enforcing connection limits and is much more predictable than GracePeriod, combining it with GracePeriod in case X number of connections are never reached should achieve a more robust and router-friendly system then is currently in place.

@Winterhuman Winterhuman added the need/triage Needs initial labeling and prioritization label Jan 2, 2022
@TheDiscordian
Copy link
Member

TheDiscordian commented Jan 2, 2022

This issue was created after some hot debate around router-kill problems in chat mostly referenced here: ipfs/kubo#3320

@Winterhuman Winterhuman changed the title GraceLimit instead of GracePeriod GraceLimit Jan 2, 2022
@Winterhuman
Copy link
Author

Now that go-libp2p has the ResourceManager, this probably isn't necessary anymore; it essentially provides the same functionality as this, only it uses memory usage instead of number of connections. Closing the issue

@ShadowJonathan
Copy link

@Winterhuman No, my problem with IPFS is not that it will get too much memory, but that it is opening way too many connections at all times, I want this feature so i can stricly limit my network usage.

Please reopen this issue.

@markg85
Copy link

markg85 commented Jul 29, 2022

I second that opinion @ShadowJonathan
@Winterhuman, having it in go-libp2p is great but won't solve it for IPFS (kubo). Is there a way to get that option in kubu without rebuilding it and going manual route?

@aschmahmann
Copy link
Contributor

aschmahmann commented Jul 29, 2022

but won't solve it for IPFS (kubo)

So either way this doesn't belong in the specs repo, it's an implementation specific (i.e. kubo in this case) concern.

However, you should be able to set hard connection limits using https://github.com/ipfs/kubo/blob/master/docs/config.md#swarmresourcemgr (i.e. as detailed in the kubo release notes and config file documentation the go-libp2p resource manager is exposed for configuration)

@markg85
Copy link

markg85 commented Jul 29, 2022

@aschmahmann I completely forgot about that (so much new stuff these last few months). I'm in the house with the crap-modem tomorrow so I'll be sure to give that a try and see how it works for me. Reporting back in a few days in ipfs/kubo#3320 with my findings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

5 participants