-
Notifications
You must be signed in to change notification settings - Fork 87
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
Diffusion improvements #5070
Diffusion improvements #5070
Conversation
987d6c9
to
cf13ae7
Compare
44a505f
to
a84ba63
Compare
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 don't think my PR is leaking network details. It is setting up a different API. Currently, cardano-node
is only one possible client of our diffusion so we must not entirely tailor our API to it, we need to be sensible for others too. For instance, I'd prefer that the extension points were all in the same top level/entry data types and then the diffusion library would make the plumbing itself, also from a type signature perspective it is more clear to me where I should have my extension data types.
Removing extraActions
just because they can be computed from extraArgs
in the cardano node case doesn't mean it is going to be the same case for all other applications. So we might be simplifying things for cardano-node case and making things difficult for the others...
The same for the extraAPI
... for cardano-node
it is easy to optimise for, but I don't like removing the extension point from the main Consensus API data type LedgerConsensusInterface
because it makes it harder (imo) to see where one would extend the API.
I don't disagree with these changes but I think they are missing the bigger picture. We can improve our API without making it worse for non-cardano clients.
a84ba63
to
7e02959
Compare
68204a5
to
eb5f6a5
Compare
It's not needed.
eb5f6a5
to
6a1b9d2
Compare
They are passed as a closure, no need to leak them outside of `Cardano` (or any other 3rd party integration).
Instead of specifying `extraAPI ~ ()` for non-p2p, we can make it polymorphic. This way both p2p & non-p2 `Application` type is using the same type variables, and the wrapper type can be removed. This is more in-line with removal of non-p2p code base.
Also adhere to the convention: first `extraFlags`, then `extraPeers`
We can pass `PeerSelectionInterfaces` to `updateWithState` function to get access to `readUseLedgerPeers`.
1c37cdf
to
d700faa
Compare
, updateWithState = \PeerSelectionInterfaces { readUseLedgerPeers } | ||
PeerSelectionActions { getLedgerStateCtx, | ||
peerSharing } | ||
psv st -> do | ||
associationMode <- readAssociationMode readUseLedgerPeers | ||
peerSharing | ||
(Cardano.bootstrapPeersFlag (extraState st)) | ||
updateOutboundConnectionsState | ||
Cardano.updateOutboundConnectionsState | ||
(lpExtraAPI getLedgerStateCtx) |
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.
nice!
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.
LGTM! Thank you @coot
Description
There will be more...
Checklist
Quality
Maintenance
ouroboros-network
project.