-
Notifications
You must be signed in to change notification settings - Fork 83
[p2p] Add p2p::collector
#1205
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
base: main
Are you sure you want to change the base?
[p2p] Add p2p::collector
#1205
Conversation
p2p/src/collection/mod.rs
Outdated
/// Interface for the application that originates messages. | ||
pub trait Originator: Clone + Send + 'static { | ||
type PublicKey: PublicKey; | ||
type ID: Debug + Send + 'static; |
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 think we should use Array
here for consistency elsewhere in the codebase?
Like:
monorepo/resolver/src/p2p/mod.rs
Lines 52 to 53 in da9ba14
/// Type used to uniquely identify data. | |
type Key: Array; |
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.
Makes me wonder if resolver
should also be considered a p2p/utils
(given it is of the same ~complexity as collector
)?
Or we make collector
standalone?
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.
Given that broadcast
is also standalone, maybe collector
should also be for now.
p2p/src/collection/actor/ingress.rs
Outdated
fn send( | ||
&mut self, | ||
message: Self::Message, | ||
transformer: fn(Self::Message, Self::PublicKey) -> Bytes, |
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 think this should instead be:
send(PublicKey, message)
(can call commitment()
on message
to use for tracking outstanding).
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.
This may also make it simpler to manage the message (to avoid putting it in a big struct and then pulling it apart into bytes during send).
fn send(&mut self, message: Self::Message) -> impl Future<Output = ()> + Send; | ||
|
||
/// Peek at the collected responses for a given ID. | ||
fn peek( |
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.
If we store received messages in some sort of order, could be much more efficient to peek at indices (to avoid so much memory allocation).
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #1205 +/- ##
==========================================
- Coverage 91.28% 90.30% -0.98%
==========================================
Files 216 220 +4
Lines 58364 52790 -5574
==========================================
- Hits 53278 47673 -5605
- Misses 5086 5117 +31
... and 169 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Fixes #1114
Work-in-progress
TODO:
Request::commitment()
to each peer, but doesn't change the message on a per-peer basis. Perhaps instead ofCommitable
there must be a new, similarShardable
trait that can produce a new message/digest whenShardable::shard(self, shard_by: Self::ShardBy) -> Self::Shard
is called on the item.