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

[addrmgr] Update to make use of upcoming database #581

Open
davecgh opened this issue Dec 14, 2015 · 0 comments
Open

[addrmgr] Update to make use of upcoming database #581

davecgh opened this issue Dec 14, 2015 · 0 comments

Comments

@davecgh
Copy link
Member

davecgh commented Dec 14, 2015

The address manager package (addrmgr) for handling available peers currently uses a serialized JSON file for persistence and keeps all known addresses in memory. This is not ideal since, as the number of known good addresses grows, so too does memory consumption (albeit at a pretty slow rate). For example, recent profiling showed it using almost 50 MB on my system currently. Another issue with the current approach is the periodic serialization of the address states has to write a lot more data than is necessary.

It would be ideal to modify the package to take allow it to take advantage of the new bucket capabilities provided by the upcoming redesigned database (#380). However, since the package is also quite useful for non btcd-specific applications, tying it to the new database directly should be avoided. Thus, I propose the package should introduce a new interface which it uses to load and store the relevant data. With the interface in place, callers can provide any concrete implementation of it they need to. For example, btcd could simply implement the interface using the new database capabilities once they're in place and btcwallet could do the same using its database.

In order to provide a smooth transition and default functionality for callers that don't care, as well as tide the package over until the new database lands, I also propose implement taking the current JSON code as a default concrete implementation of the interface. With this in place, the package can be updated now and existing callers can simply use the provided default implementation without any change in behavior. Then, once the new database lands, it would be a simple matter of providing a different concrete implementation to make use of it.

jrick added a commit to jrick/btcd that referenced this issue Feb 17, 2017
Go 1.8 is out and by policy we only support the latest two Go releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant