WebTransport client

[yoursunny]

Currently, this package only offers a WebTransport server implementation. It is desirable to have a WebTransport client implementation also in this package. The benefit is that, having a WebTransport client implementation allows automated end to end testing of a WebTransport server at the protocol level, as well as remote monitoring of a WebTransport application server.

[tchakabam]

Strongly agree, you may want to have a look at https://github.com/marten-seemann/webtransport-go

[tchakabam]

I am currently trying to figure the pros/cons of this package vs the marten-seemann one (which at first sight seems more complete, also regarding the aspect the OP here mentions).

Anyone is able to give some clues?

[yoursunny]

adriancable/webtransport-go has datagrams but lacks client side. marten-seemann/webtransport-go has client side but lacks datagrams.

I'm using this package in NDN-webtrans that translates between WebTransport datagrams and plain UDP. I want a Go package that has both client side and datagrams, so that I can monitor the uptime of the NDN-webtrans deployment.

[adriancable]

This package significantly predates Marten Seemann’s work and was developed as part of another project (that needed a WebTransport server). I released it to the community because at the time there wasn’t anything else available and I thought it might be useful to others.

I definitely expect that at some point in the future Martin’s work will do everything this package does and more, in which case this package won’t have any usefulness. I’m not sure if we’re there yet.

[tchakabam]

I definitely expect that at some point in the future Martin’s work will do everything this package does and more, in which case this package won’t have any usefulness. I’m not sure if we’re there yet.

@adriancable Makes sense! Thanks for the clarification.

It seems regarding the datagram part, the current diff between the two project will actually be of importance here in my case.

I released it to the community because at the time there wasn’t anything else available and I thought it might be useful to others.

Good job, and thanks as well :) It seems then, you aren't planning to keep this project maintained from your side at all, or do not have any appropriate requirement on your work/business side to do it?

[adriancable]

It seems then, you aren't planning to keep this project maintained from your side at all, or do not have any appropriate requirement on your work/business side to do it?

I don't see any need to keep it maintained. We ended up not having a need to deploy a WT service in production (for non-technical reasons that aren't particularly interesting). quic-go and/or webtransport-go should/will support a full implementation of WebTransport out of the box, and I am sure that it soon will. In the mean time, if there's something you need from WebTransport that my 'stopgap' package doesn't provide, you are free to add it yourself. I made it available under the MIT license for this reason.

Hope this is helpful!

[tchakabam]

@adriancable Yes, totally. Thanks for the reply, take care :)

Regarding patches here, I already have one ready regarding the quic-go latest version compat (also see https://github.com/adriancable/webtransport-go/pull/3).

But you are therefore saying that you wouldn't take any PRs on this repo either way?

We are actually also going for the reliable (non-datagram) case, and might be benchmarking both libs against each other for the server side. Just being curious to see if there is a noticeable difference in any case :) While I also agree to believe that Marten's implementation is what we should support in the future, as it is going to be developed further.

[adriancable]

@tchakabam - I'd be interested to see the results of the benchmarks! I don't expect much difference, but if (for example) Marten's implementation is slower then I'd be more than happy to work with him to try to address that.