-
Notifications
You must be signed in to change notification settings - Fork 232
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
Comments
This issue was created after some hot debate around router-kill problems in chat mostly referenced here: ipfs/kubo#3320 |
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 |
@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. |
I second that opinion @ShadowJonathan |
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) |
@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. |
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.
The text was updated successfully, but these errors were encountered: