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

Improve p2p encapsulation by backporting CConnman #2558

Open
Pythonix opened this issue Aug 2, 2022 · 4 comments
Open

Improve p2p encapsulation by backporting CConnman #2558

Pythonix opened this issue Aug 2, 2022 · 4 comments

Comments

@Pythonix
Copy link
Contributor

Pythonix commented Aug 2, 2022

Feature Request

Describe the Feature Request
The Gridcoin net code is relatively old and still uses quite a few global variables. A backport of CConnman could improve this and improve some of the net code.

Describe Preferred Solution
A backport of the following pr bitcoin/bitcoin#8085

Describe Alternatives
Alternatively, we could also try to renew the net code following the plan outlined by PIVX: PIVX-Project/PIVX#1374

@jamescowens
Copy link
Member

jamescowens commented Aug 2, 2022

Hmm. I think we should discuss this as a group. I am not sure I want to travel all of the byways of Bitcoin as they evolved their codebase after the initial commits of major pieces of functionality, such as the connection manager. I would rather jump to the latest code chunk by chunk if we can make that happen. It may not be possible. A quick perusal of the PIVX project seems to indicate that is the approach they took.

Also there are certain things we have ported over that we have changed a bit which surround the net code, such as the ban manager and misbehavior routines, and I am not sure I want to follow the Bitcoin head in every instance. Some of the stuff we did I actually like better.

In general in backports of major pieces, we have backported CURRENT versions of the code, so we skip all of the intervening bugs, etc. (and instead create new backport bugs... :) ).

@Pythonix
Copy link
Contributor Author

Pythonix commented Aug 3, 2022

Yes, you are probably right and it makes more sense to try to update the code directly to the newest version. But if we at least backport the commits that split the code into new files, I think this will make it easier to update since you can selectively update files and the individual change sets will be smaller.

@jamescowens
Copy link
Member

@Pythonix you ready to get moving on this?

@Pythonix
Copy link
Contributor Author

Pythonix commented Dec 4, 2022

@jamescowens Yes, I will try to work on that in the coming weeks.

@jamescowens jamescowens added this to the Natasha milestone Feb 6, 2024
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

3 participants