3 ms·

> WebRTC data channels support peer-to-peer communications, but WebTransport only supports client-server connection. If you have multiple clients that need to t

> WebRTC data channels support peer-to-peer communications, but WebTransport only supports client-server connection. If you have multiple clients that need to talk directly to each other, then WebTransport isn't a viable alternative. That's disappointing. I have a peer-to-peer application where I'd like to be able to use QUIC streams rather than the current SCTP-based WebRTC data channels. In particular, it seems to me that QUIC streams would be better for transferring files peer-to-peer in a way that takes full advantage of available bandwidth without causing congestion or doing excess buffering on the sending end.

felipellrocha 4y ago
If you are doing p2p, though, webrtc makes a lot of sense since the apis there are designed to punch through a nat
jeffparsons 4y ago
As a user of QUIC, I've found it to be pretty much everything I've been wanting for the last 20 years. Hopefully WebTransport can grow the features required (e.g. by stealing them from WebRTC) to make real P2P WebTransport possible. Edit: if I'm reading this correctly, then maybe there are already efforts underway to make this possible: https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport
- CMCDragonkai 4y ago
  Do you see any resources on hole punching with QUIC, and NAT traversal? So far I can't even easily find a reference in existing QUIC libraries if it is possible to just send single QUIC packets to perform only hole punching while having separate streams to be established when the punch packets pass through.
  - pthatcherg 4y ago
    You can use ICE and QUIC together. That's what the original version of WebTransport did (back when it was called QuicTransport).
pthatcherg 4y ago
There's nothing stopping QUIC from being p2p. In fact, the original version of WebTransport was called QuicTransport and was p2p, but there was more interest in client/server use cases, so we switched focus to that. (I'm one of the original authors of the WebTransort spec and when I worked at Google years ago, some excellent engineers on my team shipped the original QuicTransport behind a field trial).

felipellrocha 4y ago

If you are doing p2p, though, webrtc makes a lot of sense since the apis there are designed to punch through a nat

jeffparsons 4y ago

As a user of QUIC, I've found it to be pretty much everything I've been wanting for the last 20 years. Hopefully WebTransport can grow the features required (e.g. by stealing them from WebRTC) to make real P2P WebTransport possible. Edit: if I'm reading this correctly, then maybe there are already efforts underway to make this possible: https://github.com/w3c/p2p-webtransport https://github.com/w3c/p2p-webtransport

CMCDragonkai 4y ago
Do you see any resources on hole punching with QUIC, and NAT traversal? So far I can't even easily find a reference in existing QUIC libraries if it is possible to just send single QUIC packets to perform only hole punching while having separate streams to be established when the punch packets pass through.
- pthatcherg 4y ago
  You can use ICE and QUIC together. That's what the original version of WebTransport did (back when it was called QuicTransport).

pthatcherg 4y ago

There's nothing stopping QUIC from being p2p. In fact, the original version of WebTransport was called QuicTransport and was p2p, but there was more interest in client/server use cases, so we switched focus to that. (I'm one of the original authors of the WebTransort spec and when I worked at Google years ago, some excellent engineers on my team shipped the original QuicTransport behind a field trial).