-
Notifications
You must be signed in to change notification settings - Fork 2
feat: fix compat with Rust, enable Ping + Identify #85
Conversation
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
Enable the built-in `ping` behaviour in all Zinnia peers. Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
| ); | ||
| let server_task = { | ||
| let listener_addr: Multiaddr = "/ip4/127.0.0.1/tcp/10458".parse().unwrap(); | ||
| listener_swarm.listen_on(listener_addr.clone()).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.
@mxinden What is the canonical way for setting up a Swarm listening on an ephemeral port?
I want to write something like this - notice the port is 0 (/tcp/0):
let listener_addr: Multiaddr = "/ip4/127.0.0.1/tcp/10458".parse().unwrap();
listener_swarm.listen_on(listener_addr.clone()).unwrap();
// 1. wait until OS binds the port a specific number
// 2. get the updated multi address
// E.g. the function implementing (1) can return a future of the new multiaddrThere 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.
You can call listen_on("/ip4/127.0.0.1/tcp/0".parse().unwrap()).unwrap() and then wait for a SwarmEvent::NewListenAddr.
|
@mxinden This is the finished and polished version of the changes we made together in our pair-programming session yesterday. If you have the bandwidth to take a look, then your feedback is very welcome! |
Signed-off-by: Miroslav Bajtoš <oss@bajtos.net>
mxinden
left a comment
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.
Sorry for the delayed review.
| let server_id_keys = identity::Keypair::generate_ed25519(); | ||
| let server_peer_id = server_id_keys.public().to_peer_id(); | ||
| let mut server_transport = create_transport(&server_id_keys).unwrap(); | ||
| let listener_id_keys = identity::Keypair::generate_ed25519(); |
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.
Note that the new libp2p-swarm-test crate can help with all this boilerplate:
https://github.com/libp2p/rust-libp2p/tree/master/swarm-test
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.
@mxinden thank you for the tip, the helpers in the swarm-test crate look really helpful! I would love to use listen, see #85 (comment)
There is a catch though: the swarm-test crate is not re-exported by libp2p and it's not published as a standalone crate to crates.io either :(
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.
Do you know how I can use swarm-test from my code?
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.
Cross referencing libp2p/rust-libp2p#3629 here.
Allows folks like @bajtos to use the crate, see CheckerNetwork/zinnia#85. I opted for not exposing the crate through the `libp2p` meta crate as it is a testing tool only. @thomas let me know if you prefer me to do so. Pull-Request: #3629.
Enable handling of
PingandIdentifyrequests by all Zinnia nodes.This fixes compatibility with the rust-libp2p implementation of Ping protocol, which we need to allow us to test our request-response-like behavior against a Ping protocol implementation.
This is a follow-up for
and a part of