-
Notifications
You must be signed in to change notification settings - Fork 12
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 mixnode
and mixnet-client
crate
#302
Conversation
* Add pruning methods * Call pruning on node step method * Fix tally retain closure
* Update sim engine on timeout qc * Remove rebuild method
* implement research overlay * Add branch overlay * Branch overlay config in simulation * Remove research related extensions * Use branch_depth and chunks --------- Co-authored-by: Gusto <bacvinka@gmail.com>
mixnet/client/src/receiver.rs
Outdated
message_reconstructor: Arc<Mutex<MessageReconstructor>>, | ||
) -> Result<(), Box<dyn Error>> { | ||
let mut buf = Vec::new(); | ||
socket.read_to_end(&mut buf).await?; |
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.
Just to confirm, I guess this means a new connections is opened for each new message? This would indeed make sense given route is dynamic
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.
Yes, for now. Later, I think we need to introduce better connection managements at some point, depending on how often the mixnet topology is updated. For example, Nym mixnodes stay connected with mixnodes in the next layer because they updated the topology once a day or an hour, iirc.
mixnet/client/src/receiver.rs
Outdated
socket.read_to_end(&mut buf).await?; | ||
|
||
let payload = Payload::from_bytes(&buf)?.recover_plaintext()?; | ||
let fragment = Fragment::try_from_bytes(&payload)?; |
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.
no chunks?
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 I understand your comment correctly, this function just receives a single fragment (chunk) and throws it to the message reconstructor. The message reconstructor keeps all fragments previously received, in memory. If the message can be finally reconstructed with the newly received fragment, the message reconstrcutor returns the message fully reconstructed.
mixnet/topology/src/lib.rs
Outdated
let mut route: Vec<route::Node> = Vec::new(); | ||
|
||
for layer_id in 0..num_hops { | ||
let layer = self.layers.get(layer_id).unwrap(); |
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.
it's not clear from the api that layer_ids are incremental
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.
Thank you. I just realized that we don't actually need the LayerId
type: ea23c6e
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 also simplified the API by removing the num_hops
: b8d3bad. We can revive it later after the first iteration is done.
mixnet/topology/src/lib.rs
Outdated
} | ||
|
||
impl Layer { | ||
pub fn random_node(&self) -> Option<&Mixnode> { |
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.
we should probably ask the caller to provide the source of randomness
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.
Good point: 2fd055b.
I had to downgrade the rand
and rand_xoshiro
in the integration test, because nym-sphinx
depends on the rand@v0.7.3
. If we use the rand@v0.8
, the following error occurs:
--> mixnet/client/src/sender.rs:65:35
|
65 | .split_into_fragments(rng, plaintext_size_per_packet)
| -------------------- ^^^ the trait `rand_core::RngCore` is not implemented for `R`
bf10cc3
to
9a1d94f
Compare
9a1d94f
to
ea23c6e
Compare
* Handle finished simulation * Flush remaining records to the sink * Write runtime metadata last
b7563e4
to
9b53c10
Compare
* Add rs lib, implement encoding * Implement decoding
80e49f2
to
9b53c10
Compare
tests/src/tests/mixnet.rs
Outdated
let mut msg = [0u8; 100 * 1024]; | ||
rand::thread_rng().fill_bytes(&mut msg); | ||
|
||
let res = client1.send(msg.to_vec(), destination, &mut OsRng, topology.layers.len()); |
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.
@zeegomo @danielSanchezQ
I just changed the mixnet design a bit in the PR #307, so that the message sender doesn't need to specify the mixnet destination explicitly. Please review that PR together with this PR. I put detailed descriptions there.
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.
We can go ahead with this. 🚀
@zeegomo I'm merging this PR since I've applied your suggestions and there have been many architectural changes (especially in PR #307). I think it's better to merge this now to the |
9be1b8f
to
84dfb0f
Compare
c338f15
to
77dc749
Compare
* Add `mixnode` and `mixnet-client` crate (#302) * Add `mixnode` binary (#317) * Integrate mixnet with libp2p network backend (#318) * Fix #312: proper delays (#321) * proper delays * add missing duration param * tiny fix: compilation error caused by `rand` 0.8 -> 0.7 * use `get_available_port()` for mixnet integration tests (#333) * add missing comments * Overwatch mixnet node (#339) * Add mixnet service and overwatch app * remove #[tokio::main] --------- Co-authored-by: Youngjoon Lee <taxihighway@gmail.com> * fix tests for the overwatch mixnode (#342) * fix panic when corner case happen in RandomDelayIter (#335) * Use `log` service for `mixnode` bin (#341) * Use `wire` for MixnetMessage in libp2p (#347) * Prevent tmixnet tests from running forever (#363) * Use random delay when sending msgs to mixnet (#362) * fix a minor compilation error caused by the latest master * Fix run output fd (#343) * add a connection pool * Exp backoff (#332) * move mixnet listening into separate task * add exponential retry for insufficient peers in libp2p * fix logging * Fix MutexGuard across await (#373) * Fix MutexGuard across await Holding a MutexGuard across an await point is not a good idea. Removing that solves the issues we had with the mixnet test * Make mixnode handle bodies coming from the same source concurrently (#372) --------- Co-authored-by: Youngjoon Lee <taxihighway@gmail.com> * Move wait at network startup (#338) We now wait after the call to 'subscribe' to give the network the time to register peers in the mesh before starting to publish messages * Remove unused functions from mixnet connpool (#374) * Mixnet benchmark (#375) * merge fixes * add `connection_pool_size` field to `config.yaml` * Simplify mixnet topology (#393) * Simplify bytes and duration range ser/de (#394) * optimize bytes serde and duration serde --------- Co-authored-by: Al Liu <scygliu1@gmail.com> Co-authored-by: Daniel Sanchez <sanchez.quiros.daniel@gmail.com> Co-authored-by: Giacomo Pasini <Zeegomo@users.noreply.github.com>
Implemented the
mixnode
andmixnet-client
crate, according to https://www.notion.so/Mixnet-Architecture-613f53cf11a245098c50af6b191d31d2.NOTE:
mixnet
branch, not themaster
.CHANGES:
mixnode
: A core crate for implementing the mixnode binarymixnet-client
: A client library for mixnet users (such as nomos-node)mixnode
s.mixnodes
s and re-assemble the message.TODO:
nomos-mixnode
binary using themixnode
crate.mixnet_client
crate with Nomos network backends.