Does the new QUIC experiment lead to potential P2P applications?

[CMCDragonkai]

We are evaluating quic as an alternative to uTP for a P2P system.

However quic implementations are lacking in the JS ecosystem.

The nodejs quic implementation seems stalled, but I found your article about experimenting with QUIC with this library.

I am a bit confused about the naming of this library, it seems focused on websockets. But if quic is coming into this library, I'd like to know whether you'll exposing low level quic functionality to JS, and whether we can use it to do bidirectional hole punching for NAT traversal which is necessary for P2P applications.

[ghost]

I am a bit confused about the naming of this library

Me too. I guess it made sense in 2016 when all it did was WebSockets.

The nodejs quic implementation seems stalled

This implementation here is also a bit stalled, esp. since WebTransport is stalled in lsquic. Everything kind of stalls when so many parts are involved

[CMCDragonkai]

When it does come to fruition, do you have plans for ensuring that hole-punching network address traversal is possible? That would be necessary for any P2P applications.

[ghost]

When it does come to fruition, do you have plans for ensuring that hole-punching network address traversal is possible? That would be necessary for any P2P applications.

uWS with QUIC only cares about UDP, if you want to support bidirectional UDP in cases of strict NAT's then you need to solve that as a separate solution (such as having a signalling server that keeps peer-IP/port pairs and then emitting UDP packets to those).

[uasan]

I am a bit confused about the naming of this library

uNetworking/uWebSockets#1112 (comment)

This implementation here is also a bit stalled, esp. since WebTransport is stalled in lsquic. Everything kind of stalls when so many parts are involved

Perhaps it makes sense to make a version without WebTransport support, so as not block progress for support H3?
This allow to refuse reverse proxies (Nginx, etc) for uWS backend, using H3 is already a big improvement.

[CMCDragonkai]

This is fine, we already have a solution for signalling. But as long as uWS quic provides the underlying datagrams to send.

On 17 July 2022 9:05:12 am AEST, Alex Hultman ***@***.***> wrote: > When it does come to fruition, do you have plans for ensuring that hole-punching network address traversal is possible? That would be necessary for any P2P applications. uWS with QUIC only cares about UDP, if you want to support bidirectional UDP in cases of strict NAT's then you need to solve that as a separate solution (such as having a signalling server that keeps peer-IP/port pairs and then emitting UDP packets to those). -- Reply to this email directly or view it on GitHub: #763 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ghost]

Yes the only system level foundation for QUIC is UDP in/out. It doesn't care about anything else