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

Add peer handling diagram. #39

Merged
merged 1 commit into from
Oct 1, 2019
Merged

Add peer handling diagram. #39

merged 1 commit into from
Oct 1, 2019

Conversation

hdevalence
Copy link
Contributor

This has the export of something I sketched in Monodraw; I'd like to upload the original Monodraw file but I'm not sure if other people also use it and what information it embeds in the binary.

│ ┌────────────┐ are requests │
│ │ Framed │ │
│ │ Messages │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─
│ └────────────┘ last-seen timestamp channel │ │
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a hook on the receiving end of the framed stream can fire a (SocketAddr, DateTime<Utc>) pair into an async mpsc channel before continuing to process the message.

│ │ │
┌───────────┼────────────────────────┼──────────┐
│ │ PeerSet: two Services │ │ │
│ │ plus bookkeeping ▼ │
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PeerSet maintains a pool of connected peers and is responsible for dynamically determining the peerset size.

The PeerSet contains a client and server Service`.

The server Service collects requests from all connected peers and routes them / load balances across internal services. Its poll_ready implementation should use backpressure information from all the inbound requests it sees to determine when the backing services are overloaded by the external network, and if so, drop a request, causing the PeerServer to terminate the connection, contracting the peerset (and reducing load).

The client Service collects requests from internal services and load balances them across available peer connections. Its poll_ready implementation should use backpressure information from outbound requests it sees to determine when additional peers are needed to handle outgoing requests (e.g., attempting to download many blocks at once), and then asynchronously construct new peers via the PeerConnector service. It should probably also have a slight bias towards expanding the peerset size, so that we have a "full" set of peers by default.

└───────────────────▶│ rsp: Vec<MetaAddr> │
│ │
│ truncates timestamps │
└─────────────────────────────┘
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is an example of only one internal service, an AddressGossip service used to respond to getaddr requests, which pulls the (authenticated) last-seen info from the AddressBook and truncates timestamps.

@dconnolly
Copy link
Contributor

image

@hdevalence
Copy link
Contributor Author

For the "PeerSet", I think we probably want to study the tower_balance implementations; because we want to have some "duplexed" resizing behaviour I am guessing that we won't be able to use them directly, but seeing how they work would be useful.

@dconnolly dconnolly merged commit 5939857 into main Oct 1, 2019
@dconnolly dconnolly deleted the peer-diagram branch October 1, 2019 17:05
skyl added a commit to skyl/zebra that referenced this pull request Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants