Adding a webrtc test

[John-LittleBearLabs]

No description provided.

[John-LittleBearLabs]

Doesn't look like I can add reviewers, likely related to the target repo's rules.
@GlenDC @ckousik @ddimaria

I don't think I should switch to "ready" until I can stop pointing at Chinmay's repository (i.e. after webrtc lands in go-libp2p). Does that sound right to you folks?

[GlenDC]

why is local:exec and cluster:k8s enabled?

[John-LittleBearLabs]

Didn't think about it too much, but is there any particular reason this test couldn't be run in those circumstances?

[GlenDC]

I would think that local:exec needs a different builder, the k8s one I do not know

[GlenDC]

why a max of 10000? How do you ever expect such numbers to be reached?

[John-LittleBearLabs]

The thing I changed here was to lower the default.

I would guess if someone asked for 10000 they're actually expecting the system to break and want to see what happens when it does. Though I don't really know.

[GlenDC]

Hmmm ok. Seems odd, but plausible.

[mxinden]

Wonderful to see this happening. Thanks @John-LittleBearLabs for working your way through this stack. Thanks @GlenDC for the review.

Today we only test the TCP transport via the ping tests. Long term we will test:

• TCP
• QUIC
• WebRTC
• WebTranport
• ...

With the above in mind, I think it makes sense to think of this pull request not as a one-off, but as a pull request that introduces an abstraction to https://github.com/libp2p/test-plans that enables us to test a variety of transports.

I haven't put enough thoughts into the ideal abstraction, thus I am happy for input. What I have today:

• Extend the ping test with an additional transport parameter (we have max_latency_ms and iterations today). For now transports could be one of tcp and webrtc.
• Depending on the transport parameter value, listen on either tcp or webrtc.
• Extend the composition files to run with both tcp and webrtc. I would appreciate input from @laurentsenta here on how to best do this. Templating? Separate composition files?

[John-LittleBearLabs]

@mxinden per your comment, ping/_compositions/go-webrtc.toml sets the transport flag to "webrtc" (the default is "tcp").

A couple complications:

• go.toml - the versions of go that are compared under go-cross-versions.toml - none of these versions have the webrtc transport in them. So I added recent.go-toml with basically just the one version that does (and I think that file should probably be renamed).
• The "version" that does have webrtc is in Chinmay's fork, which is why I consistently refer to that "version" as "ckousik". And the modfile & composition file still have some wonkiness to deal with that oddity.

[mxinden]

Thanks @John-LittleBearLabs for looking into this!

A couple complications:

* go.toml - the versions of go that are compared under go-cross-versions.toml - none of these versions have the webrtc transport in them. So I added recent.go-toml with basically just the one version that does (and I think that file should probably be renamed).

* The "version" that _does_ have webrtc is in Chinmay's fork, which is why I consistently refer to that "version" as "ckousik". And the modfile & composition file still have some wonkiness to deal with that oddity.

This sparked the following proposal #53. We would define the supported transports per version. If I am not mistaken, this should resolve the issues above. Does that sound reasonable? //CC @laurentsenta

[John-LittleBearLabs]

@mxinden

Does that sound reasonable?

Yes I do see how that approach does solve this. I'll think about this for a bit, and then I think I'll have a question or two but should probably put it in that other PR.

[p-shahi]

@John-LittleBearLabs Should this be closed in favor of #67 ?

[John-LittleBearLabs]

@p-shahi

@John-LittleBearLabs Should this be closed in favor of #67 ?

This one has the advantage that the last time I tried to run it it worked.

That said, neither of these should get merged in while they still depend on Chinmay's private repo.
Once libp2p/go-libp2p#1655 is resolved & merged & released, I'd have to update one or both of these. Might as well only update the one that's more in line with the future vision.

So yeah, let's close this.