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

Break down responsibilities of core-p2p classes #2362

faustbrian opened this Issue Apr 3, 2019 · 0 comments


1 participant
Copy link

faustbrian commented Apr 3, 2019

Currently the peer "model" is a nightmare from another dimension. Instead of being a dumb DTO/POJO it also knows what to do with the data it holds and how to process it.

It should only hold the data and other methods accept an instance of IPeer to perform actions like broadcasting transactions.

The monitor is the central entry point of the core-p2p plugin and handles accepting, rejecting, banning, monitoring and collecting of peers. Those tasks should be broken down into a PeerProcessor, NetworkMonitor and PeerCommunicator which each will have one specific type of tasks.

The PeerProcessor will take care of accepting, rejecting, banning and storing peers. A prerequisite for storing the peers will be the introduction of a PeerRepository which will provide convenient methods for checks on all stored peers.

The NetworkMonitor will perform all bulk actions on peers like clear out peer lists, remove old peers and discover new ones. Everything that is required to gather information about the network or to interact with it will be going through this.

The PeerCommunicator will take care of communication with a single peer where an IPeer instance is expected by al methods. This will mainly be an abstraction of all the business logic that is currently inside the peer model.

At the moment the peer guard takes care of deciding what punishment a peer should received and also applies it together with storing the peer. The guard should only make a decision about the punishment and the PeerProcessor will take care of storing the peer and it's punishment.

Connecting all parts
All of those parts will be connected through a PeerService that will be bound to the container as p2p to replace the current binding of the Monitor as main entry point.

The PeerService will be composed as new PeerService(new PeerCommunicator, new PeerProcessor, new NetworkMonitor) which makes testing easy as we can simply provide stubbed implementations instead of mocking a dozen properties and methods.

The way it is composed is subject to change as the actual implementation is done but you get the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.