-
Notifications
You must be signed in to change notification settings - Fork 493
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
network: unify wsPeerCore use for HTTP and p2p HTTP transport #5933
network: unify wsPeerCore use for HTTP and p2p HTTP transport #5933
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## feature/p2p #5933 +/- ##
===============================================
- Coverage 56.08% 56.06% -0.02%
===============================================
Files 481 481
Lines 68072 68053 -19
===============================================
- Hits 38180 38157 -23
- Misses 27281 27290 +9
+ Partials 2611 2606 -5 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I think this is an improvement so am marking approved. It would be nice if there was a rich type for address that handled whether its for http or multiaddr at construction (making it a property of a struct, removing some checks, etc) but not a show stopper.
@@ -92,7 +92,7 @@ type GossipNode interface { | |||
|
|||
// GetHTTPClient returns a http.Client with a suitable for the network Transport | |||
// that would also limit the number of outgoing connections. | |||
GetHTTPClient(peer HTTPPeer) (*http.Client, error) | |||
GetHTTPClient(address string) (*http.Client, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any benefit to consider around using a stronger type than string here? I.E. enforcing formatting etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this in previous PR, HTTPPeer
type was needed only to get its address to reconstruct p2p transport. both ws and p2p implementations fail on parsing so I think it is OK
Also thought about wrapping address - looked a bit bigger change, maybe in subsequent PRs as needed. |
Summary
wsPeerCore
refactoring aiming to makeHTTPPeer
to use "get path and fire request` approach rather than analyzing peer/url type.Before:
wsPeerCore
hasrootURL
field that is used for logging, peer identification and HTTP connectivity. Its constructor also accepts aRoundTripper
(rate limiting transport) to construct a defaulthttp.Client
.Adding p2p into the mix changed the latest part - HTTP connectivity is handled by pre-created p2p http transport (and client) making the
rootURL
to serve a dual purpose (peer id as a full p2p multiaddr string, and a peer type separation field in HTTP clients code)After:
wsPeerCore
still hasrootURL
for id and connectivity but the connectivity bit is handled by pre-constructedhttp.Client
that usesrootURL
to build up a full URL. This allowed to unify peers with http and p2p transport from client's viewpoint.Test Plan
HTTPPAddressBoundTransport
type