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

First building blocks for Sharding API: ShardIndex and TransportIdentity #970

Merged
merged 8 commits into from
Mar 18, 2024

Conversation

akoshelev
Copy link
Collaborator

See #969 for overall approach.

This change introduces two fundamental concepts for horizontal scaling - ShardIndex and Transportidentity.

The former will be used the same way as HelperIdentity is used nowadays - unique identifier of a peer we are communicating with. Having in mind 200B events, we may need more than 65k shards, thus 4 byte identifier usage.

TransportIdentity is a generalization for peer identifiers used at transport layer. Two fundamental structs implement it: HelperIdentity and ShardIndex to allow communication via MPC and shard channels.

Role is used at the Gateway/Context layer for communication purposes and RoleResolvingTransport is a convenient abstraction, so it also implements TransportIdentity.

Transport trait became generic over TransportIdentity - I tested it in my private branch where I have a complete implementation, so this approach works.

I also did a bit of a refactoring and made RoleResolvingTransport to implement the Transport trait because it can now.

Refactor `RoleResolvingTransport` to make the use of it nicer
Copy link

codecov bot commented Mar 9, 2024

Codecov Report

Attention: Patch coverage is 97.14286% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 89.43%. Comparing base (af58b0f) to head (684e32e).

Files Patch % Lines
ipa-core/src/helpers/gateway/stall_detection.rs 66.66% 2 Missing ⚠️
ipa-core/src/helpers/gateway/receive.rs 75.00% 1 Missing ⚠️
ipa-core/src/helpers/gateway/transport.rs 95.45% 1 Missing ⚠️
ipa-core/src/helpers/mod.rs 66.66% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #970      +/-   ##
==========================================
+ Coverage   89.29%   89.43%   +0.14%     
==========================================
  Files         162      163       +1     
  Lines       21844    21897      +53     
==========================================
+ Hits        19505    19584      +79     
+ Misses       2339     2313      -26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

type Item = Vec<u8>;

fn poll_next(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {
self.project().0.poll_next(cx)
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is project() and where is it coming from? Is it defined in Stream?

pub struct ChannelId {
pub role: Role,
pub struct ChannelId<I: transport::Identity> {
pub peer: I,
Copy link
Collaborator

Choose a reason for hiding this comment

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

This name: peer confuses me. Why did you change this from role? What does it mean here? And can you add a comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

the reason I had to rename it is that this struct is now used to communicate between shards too and there is no notion of helper role for such communications. ChannelId<ShardIndex> would have role: ShardIndex field which looks even more confusing, hence a neutral peer that can be anything that wants to communicate with this instance

"Current shard index '{this}' >= '{max}' (total number of shards)"
);

max.iter().filter(move |&v| v != this)
Copy link
Collaborator

Choose a reason for hiding this comment

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

What does that move syntax do here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

it moves this to the closure, so Rust compiler can see that filter closure cannot outlive it. We return an iterator and filter closure is part of it, so Rust wants to know that this closure does not borrow from local context

Copy link
Collaborator

@benjaminsavage benjaminsavage left a comment

Choose a reason for hiding this comment

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

This looks pretty straightforward to me. Most of the lines are just replacing ChanelId with HelperChanelId.

@akoshelev akoshelev merged commit c531015 into private-attribution:main Mar 18, 2024
11 checks passed
@akoshelev akoshelev deleted the sharding-basic branch March 18, 2024 06:07
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