Immediate advantages
UNIX domain sockets for JSON-RPC
- Old feature request: #5029
- UNIX sockets have been added to ZMQ and Tor proxy already
- UNIX sockets with libevent doesn’t work
Remove a dependency
- libevent hasn’t had a release since 2020
- The xz utils backdoor raised some concern among contributors in the 2024/04/18 IRC meeting
Current libevent usage in the project
See this report by @fjahr. A few of these have already been addressed, like #29904
Strategies
I am starting by replacing the HTTP server, currently used for both REST and JSON-RPC and implemented with libevent. Nothing is quite ready for review yet but I have:
https://github.com/pinheadmz/bitcoin/tree/http-netbase-cmake
Still lots of TODOs and new tests to write but works and passes all current tests. In this branch I added a new http.cpp module with socket-handling code largely copied from ConnMan. This branch needs a lot of clean up before presenting as a PR with clear commits.
https://github.com/pinheadmz/bitcoin/tree/http-rewrite
This branch I am trying to write much more cleanly for PR presentation. It is based on #30988 by @vasild which cleanly separates the generic socket handling logic from the bitcoin protocol logic. It would be especially useful if there was any more future need for additional servers in bitcoin (such as @Sjors recently withdrawn proposal to add StratumV2: https://github.com/Sjors/bitcoin/pull/68)
Looking for feedback
- Is this something worth doing at all?
- We could vendor libevent instead of requiring it as a dependency, and fix UNIX sockets there
- There might be another C++ HTTP library we could import instead. I did shop around a bit but everything I found was just a bit too much.
- If(1) do we want to share generic sock manager code or have it mostly duplicated between p2p and http?
