search

WICG / local-peer-to-peer

↔️ Proposal for local communication between browsers without the aid of a server.
https://wicg.github.io/local-peer-to-peer/
Other
62 stars 6 forks source link

Large message considerations #11

Closed backkem closed 7 months ago

backkem commented 10 months ago

Since one of the screenshots indicates file dropping as a use-case, I wanted to highlight considerations for sending larger files. This was also a point of iteration for WebRTC (example).

One disadvantage of a .send( string ) and .on("message", function ) approach is that you have to either send a file in one big chunk or implement your own chunking protocol. The former requires loading the entire file into memory which could become a bottleneck and the latter requires more work by the consumer of the API.

One option that may be worth considering is to add an API inspired by WebTransport. There is an example attempt at doing this from the ORTC Community Group: p2p-webtransport. The spec doesn't have a motivation section but there is some background in w3c/webtransport#35. It would be nice if all transports (such as this proposal and WebRTC) shared this kind of API.

As a side node: the WebTransport API also has an option for unreliable streams that could be relevant to real-time (E.g. video or gaming) use-cases.

backkem commented 9 months ago

One way to see this proposal is in two pieces: A connection establishment between devices and a transport/messaging API.

Local P2P connection The connection establishment consists of the findPeers and makeDiscoverable functions in the proposal. These could be layered on networking protocols as follows:

Rendezvous APIs

In this image OSP-C refers to the connection establischment part of the OpenScreen protocol as discussed in w3c/openscreenprotocol#321.

Local P2P networking As I suggested in my original post, the networking itself could use the WebTransport API, for example over a QUIC transport that uses TLS certificates established during the connection step. These could be layered on networking protocols as follows:

Networking APIs

A simple messaging Shim/API can be layered on top of the WebTransport API to provide the ergonomics of Send/OnReceive functions.

WebRTC I wanted to quickly touch on WebRTC since it is also mentioned one of the main pictures in the spec document. I added the respective WebRTC protocols to the images above for comparison. There may be an opportunity to also align WebRTC with the APIs defined there. Using the approach once proposed by p2p-webtransport.

This could eventually provide the same API for all scenario's:

WebRTC interop

The connection establishment may be more difficult to align. I think it is feasible but it would require standardizing the 'signaling' step of WebRTC.

ibelem commented 9 months ago

Many thanks @backkem for your feedback and new created issues, we will integrate your comments when migrating this proposal to the WICG repo in Q4. Added you in the acknowledgements section.

backkem commented 7 months ago

Considered closed by #23.