-
Notifications
You must be signed in to change notification settings - Fork 111
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
Conversation
│ ┌────────────┐ are requests │ | ||
│ │ Framed │ │ | ||
│ │ Messages │─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│─ ─ ─ | ||
│ └────────────┘ last-seen timestamp channel │ │ |
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.
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 ▼ │ |
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.
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 │ | ||
└─────────────────────────────┘ |
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.
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.
For the "PeerSet", I think we probably want to study the |
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.