WebRTC Transport Layer

[ValorZard]

Adding this here just for posterity, since I already know that this is in the plans. This would be pretty easy to test though, since bevy and other rust game frameworks already support the web, with a few being web-only in fact. Having a game with rollback on the web besides Tough Love Arena would be really cool.

[james7132]

Digging into this, it seems like webrtc-unreliable implements the minimal interface we need for a transport implementation like this, though it seems more geared towards client-server topologies. Would this be sufficient? A full P2P implementation will likely need some auxiliary support from matchmaking services like Nakama.

[ValorZard]

Copying this from @ErnWong since its important:
creating webrtc connections between two browser peers require some signalling server to help establish the connection, but there's a lot of flexibility on how this signalling server is done. But, just like how backroll_transport_udp doesn't include a matchmaking server with it (instead you just directly pass in the IP address you want to connect to), perhaps a hypothetical backroll_transport_webrtc doesn't need to include this signalling server. Instead, people who use backroll_transport_webrtc could

(1) pass in an existing webrtc connection (created using wasm_bindgen/web_sys), or
(2) pass in all the information and callbacks (or perhaps using some Commands struct just like the new backroll API) that are needed to establish a new webrtc connection.

I like (1) as well, because it seems silly to write our own layer of indirection that just forwards to the actual WebRTC interface. (1) gives more control, probably

there's quite a lot of flexibility on what the signalling server is, so you could even just use email as your signalling server for testing purposes. On your end, you'd create a new webrtc connection, get it to generate an "offer" that contains some "ICE candidates" (the information needed to establish a connection), email this offer to your friend, get your friend to email you back the "answer" that contains their "ICE candidates", and then if things are successful, you'd be connected

You might want to look at RtcDataChannel (https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.RtcDataChannel.html), and find a way to create a bevy_transport::Peer out of the data channel. The send_with_u8_array and set_onmessage functions would be useful.

(https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.RtcDataChannel.html#method.set_onmessage)
(https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.RtcDataChannel.html#method.send_with_u8_array)

[ValorZard]

Note: Ernest was mistaken when he said that we should convert it into a bevy_transport::Peer. In actuality, we want to convert it into the backroll_transport Peer data type.

[Arti-Code]

if you wonder about signaling method to establish webrtc p2p connection, I can say that one of good choices (in my opinion) is using RealtimeDB from Firebase (or some similar service). On public service like firebase two peers exchange negotiation informations and then can establist p2p connection directly.

In my case it's work very well. I use webrtc-rs im my robotic project and I can establish connection over the public internet in that way. I use datachannels and videostreams to controll robot using camera stream video in realtime