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

Peer Management #639

Open
hayesgm opened this issue Nov 20, 2018 · 1 comment
Open

Peer Management #639

hayesgm opened this issue Nov 20, 2018 · 1 comment

Comments

@hayesgm
Copy link
Contributor

hayesgm commented Nov 20, 2018

Currently when we run our sync code, we start two supervisors: ExWire.PeerSupervisor and ExWire.TCP.InboundConnectionsSupervisor. The latter is used for inbound connections, which isn't heavily supported right now. For ExWire.PeerSupervisor, when we're running discovery mode, we connect to peers as they are discovered until we reach a certain count of max peers (currently hard-coded). We don't try to connect to other peers when our connected peers drop, and again, we ignore any inbound connections. This is pretty poor behavior.

This issue is to improve peer connection management. It should do a variety of tasks:

  1. Keep track of all peers (discovered by the discovery protocol, inbound or from bootnodes / reserved peers), even if we decide not to connect. This acts as a pool of nodes we might connect to.
  2. Connect to good peers. This might be from the Kademlia distance formula, or maybe nodes we've connected to in the past, or maybe based on capabilities (e.g. connect, check the caps, and drop the node if it's not useful).
  3. Keep track of dropped connections (maybe a peer disconnected from us) and connect to new nodes when this happens. We should (probably) not reconnect to a peer after it asks to disconnect, but we should keep that peer if we just had a transport error.

This will require a good amount of work, but it's vital to getting a healthy node up and running.

@InoMurko InoMurko self-assigned this Nov 21, 2018
InoMurko pushed a commit that referenced this issue Dec 4, 2018
* WIP - linking to connections and determening cause

* WIP - testing notification and kademlia route

* fixing test because of new peer supervisor interface

* remove vscode folder ignore

* code style and format

* adding is outbound to log
@InoMurko
Copy link
Member

InoMurko commented Dec 4, 2018

Peer rating and reputation system:
The idea is that a rating consist of:

  • Capabilities of a peer (weighted if they mach ours)
  • P2p version that's being broadcasted (weighted if same or above ours)
  • Arithmetic mean of the amount of time a connection was established and the count of exchanged messages (that should give us an idea of latency and usefulness of a peer)

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

2 participants