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

Add webrtc transport multidim interop #100

Merged
merged 11 commits into from
Jan 18, 2023

Conversation

jxs
Copy link
Member

@jxs jxs commented Jan 12, 2023

No description provided.

@jxs jxs marked this pull request as draft January 12, 2023 20:20
@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch from 63efd23 to eb1ab42 Compare January 12, 2023 20:21
@mxinden
Copy link
Member

mxinden commented Jan 13, 2023

🚀 let me know once this is ready for a review.

@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch 4 times, most recently from e26ca25 to ffdaea7 Compare January 15, 2023 23:53
@jxs jxs marked this pull request as ready for review January 16, 2023 00:06
@jxs
Copy link
Member Author

jxs commented Jan 16, 2023

@mxinden thanks, ready! @MarcoPolo the tests are failing because of the "js-v0.41.0 x js-v0.41.0 (ws, noise, yamux)" which this PR doesn't affect afaict do you know what might it be?

@MarcoPolo
Copy link
Contributor

Can you rebase please. The ping succeeded, but the test failed. I think it’s because it failed when closing the Redis client (which is fine).

@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch 4 times, most recently from c0a5ace to 03721b7 Compare January 16, 2023 11:18
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

Minor comments. Good to merge from my end.

let timeout = Duration::from_secs(5);

match secure_channel_param {
"noise" => builder
Copy link
Member

Choose a reason for hiding this comment

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

As an aside, I suggest using enums here long-term instead of passing around strings. clap should make this reasonably easy. Neither important nor urgent.

Copy link
Member Author

Choose a reason for hiding this comment

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

yup, awesome idea! Updated ptal Max

await db.all(`SELECT DISTINCT a.id as id1, b.id as id2, a.transport
FROM transports a, transports b
WHERE a.transport == b.transport
-- Only webtransport transports
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
-- Only webtransport transports
-- Only webrtc transports

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! 🙏

multidim-interop/versions.ts Show resolved Hide resolved
@jxs
Copy link
Member Author

jxs commented Jan 16, 2023

CC @thomaseizinger you also probably want to take a look, as this builds on your work on the previous interop tests

@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch from 6ffa98e to f999445 Compare January 16, 2023 16:08
to allow us add the WebRTC transport test (which is only available with
the tokio runtime)
Clean up the test and update Cargo.toml to 0.2.0 to avoid conflicting with the older tests, and allow us to import lib.rs
on the rust-libp2p repo and have the master tests there.
with KeepAlive Behaviour
webrtc instead of webtransport.
@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch 3 times, most recently from fe8e932 to b251928 Compare January 16, 2023 18:03
@jxs jxs force-pushed the add-webrtc-transport-multidim-interop branch from b251928 to 396c327 Compare January 16, 2023 18:18
listenerID: test.id2,
transport: test.transport,
muxer: "quic",
security: "tls",
Copy link
Member Author

Choose a reason for hiding this comment

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

@MarcoPolo what do you think of this change? It doesn't break Go quic tests, and allows Rust to have one less Variant in the enum. Plus I'd say it makes sense semantically.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don’t think it makes sense. In every other context tls means add a tls encryption layer on top of the transport.

I know quic uses tls underneath and that isn’t a hardcoded decision (some different encryption layer could be possible in the future). But for now I think we should keep tls meaning add a tls security layer to the transport.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah you are right Marco, I reverted it int this PR so we can merge and address the rust-libp2p interop. But I also agree with @thomaseizinger on #100 (comment) if you agree we can submit a PR not using muxer nor transport for quic and webrtc cases

Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

Some thoughts, otherwise LGTM.

Comment on lines 59 to 72
let transport_param: testplan::Transport = env::var("transport")
.context("transport environment variable is not set")?
.parse()
.context("unsupported transport")?;

let secure_channel_param: testplan::SecProtocol = env::var("security")
.context("security environment variable is not set")?
.parse()
.context("unsupported secure channel")?;

let muxer_param: Muxer = env::var("muxer")
.context("muxer environment variable is not set")?
.parse()
.context("unsupported muxer")?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Until we move the test to our repository (where we deduplicate the test using Git revisions), I don't think it makes much sense to be typed here because we have to repeat it in every test.

Copy link
Member Author

@jxs jxs Jan 17, 2023

Choose a reason for hiding this comment

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

it's now all on the testplans lib, which we can depend on the rust-libp2p repo and use from there wdyt?
update: wrote this before reading libp2p/rust-libp2p#3331 (comment) let's continue there.

Comment on lines -87 to -88
muxer: "quic",
security: "quic",
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a bit odd, I think leaving these blank would make the most sense. It requires the tests to parse the variables in steps but I don't see why that is necessarily a problem.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah agree Thomas, commented on #100 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this makes sense to me. We can make this change in a future PR so we do it across all impls

use std::env;
use std::time::Duration;
use testplan::{run_ping_redis, PingSwarm};
use testplan::{run_ping, Muxer, PingSwarm, SecProtocol, Transport};

fn build_builder<T, C>(
Copy link
Contributor

Choose a reason for hiding this comment

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

This function doesn't have much value because the type constraints are so insane. You are likely better off by just inlining things and accepting the duplication between the different invocations.

Copy link
Member Author

@jxs jxs Jan 17, 2023

Choose a reason for hiding this comment

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

I still feel it's more lines of code and repetition, but feel free to submit a PR addressing that after Thomas

Comment on lines 27 to 28
Quic,
Webrtc,
Copy link
Contributor

Choose a reason for hiding this comment

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

These aren't strictly muxers. I think we should leave the muxer variable empty when we don't explicitly set one. IMO, that will be cleaner implementation.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah makes sense, thanks Thomas addressed :)

- undo generator changes, let's do that later on
- don't parse muxer and sec protocol where we don't need it
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

Changes here look good to me. Ready to merge from my end.

@MarcoPolo any objections?

security: "quic",
})))
.concat(webrtcQueryResults
.map((test): ComposeSpecification => buildSpec(containerImages, {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we indent this line? The map applies to webrtcQueryResults not the concat(...) expression like above.

Copy link
Member Author

Choose a reason for hiding this comment

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

yup makes sense Marco, updated :)

@mxinden
Copy link
Member

mxinden commented Jan 18, 2023

@jxs two approvals, all checks are green. Please merge once this is ready from your end.

@jxs jxs merged commit b0f3a2d into libp2p:master Jan 18, 2023
mxinden added a commit to mxinden/rust-libp2p that referenced this pull request Jan 20, 2023
mergify bot pushed a commit to libp2p/rust-libp2p that referenced this pull request Jan 24, 2023
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.

None yet

4 participants