This is work in progress to be able to support native clients.

It splits signalling and messages into separate async futures (and one coordinating one).

Alternative native implementations for both signalling and messaging have been added.

• [x] Figure out why no data is getting through
• [x] Make the demo work on native <-> native
• [ ] ~Add trickle implementation to wasm (otherwise cross-play will fail)~

Issue: #7

Following the same pattern as the native implementation. Now that both wasm and native support trickling, we're one step closer to supporting cross-platform connections.

TODO:

• [x] Get trickle wasm <-> wasm working
  • [ ] with negotiated = false?
• [ ] Get rid of the ugly mutex hack
• [ ] If webrtc-rs 0.5 is released, remove the candidate sdp_m_line_index hack.
• [ ] Figure out why connections on the same machine between firefox and native fails during ice
• [x] Figure out why no data seems to get through on native <-> wasm, even though peer connection state is set to connected
• [ ] Other todo comments

Issue: #7

There are some small incompatibilities between the native and wasm implementation that makes connections fail.

The native version implements ICE candidate trickling, while the wasm version does not. (#16)

• [x] expose api for setting authentication
• [x] native implementation
• [x] wasm implementation
• [x] should credential and username be String or Option<String>?
• [x] document new api
• ~~[ ] implement From trait for new enum~~

Fixes #3

As suggested by you in #61 and #25 I tried to implement a pair of data channel - one reliable and one unreliable.

To be honest I don't have much experience with asynchronous programming or webrtc and I have no idea if what I did makes any sense - I went with the gut and was simply following compiler hints until everything was green again.

However it seems to work fine in my project with both the reliable and the unreliable data channel. If you tell me that it wasn't total nonsense what I did I will try to make it a bit nicer (maybe I will manage to deduplicate some stuff and rewrite some parts a bit)

Implements #27

This is my first public Rust contribution so I am happy about feedback especially about API conventions and borrow rules

I guess we should also add some tests - but right now I am not sure if this is even possible without major refactoring...

This is an attempt to get cross data communication between native and WASM WebRTC, to address https://github.com/johanhelsing/matchbox/issues/47

The screenshot shows our own app using matchbox, 2 chrome tabs, 1 firefox tab, 2 desktop (native), all communicating with each other. We also tested order of launching and making sure no matter who offers or accepts it still connects. But this is all pretty tricky and might still have some bugs.

Recently when building my game with a non-wasm target (MacOS in my case) compile failed with something like

webrtc-srtp-0.8.9/src/context/srtp.rs:82:43 | 82 | let header = rtp::header::Header::unmarshal(&mut buf)?; | ^^^^^^^^^ function or associated item not found in rtp::header::Header |

So there seemed to be some kind of version clash between dependencies of matchbox-socket

An upgrade of 'webrtc' in matchbox-socket's Cargo.toml fixed the issue for me. I had to remove a single line of code as well which addressed a field which didn't exist any more in the new version of the crate - I have no Idea what it was for but at least it compiles again :D

I don't use matchbox yet in my game for non-wasm target builds so I can't test at the moment if it still works. I hope the PR is still helpful :)

Implements #13 This also allows to scope rooms with id. I adapted a test to use scopes, but we might want to create separate tests rather than changing the existing one.

I am having a few issues with getting p2p connections between browser tabs. In Firefox, I get the error "WebRTC: ICE failed, add a TURN server and see about:webrtc for more details" around 80% of the time (some browser logs below).

On Chrome it works every time but takes pretty long (30+ seconds!). In your video on twitter the connection seems to open quickly in firefox, so I am wondering if this changed for you, or if this is an issue with my code/browser or network.

Interesting parts from firefox webrtc logs in order (but with holes)

...
(id=23622320129 url=http://localhost:4000/)): Skipping STUN server because of address type mis-match
/build/firefox-fXSvPi/firefox-94.0+build3/dom/media/webrtc/transport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:175 function nr_socket_multi_tcp_create_stun_server_socket skipping UDP STUN server(addr:IP4:0.0.0.0:3478/UDP)
/build/firefox-fXSvPi/firefox-94.0+build3/dom/media/webrtc/transport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:175 function nr_socket_multi_tcp_create_stun_server_socket skipping UDP STUN server(addr:IP6:[::]:3478/UDP)
/build/firefox-fXSvPi/firefox-94.0+build3/dom/media/webrtc/transport/third_party/nICEr/src/net/nr_socket_multi_tcp.c:623 function nr_socket_multi_tcp_listen failed with error 3
(id=23622320129 url=http://localhost:4000/)): failed to create passive TCP host candidate: 3

block above two times
...
(id=23622320129 url=http://localhost:4000/))/CAND-PAIR(kMAM): Pairing candidate IP4:10.16.212.74:46958/UDP

... 11 seconds later
Responding with error 400: ICE Failure

ICE(PC:{7ba9e854-55ab-487c-a4bc-76d7fb530c25} <time> (id=27917287425 url=http://localhost:4000/)): Message does not correspond to any registered stun ctx

STUN-CLIENT(kMAM|IP4:10.16.212.74:46958/UDP|IP4:10.16.212.74:44090/UDP(host(IP4:10.16.212.74:46958/UDP)|candidate:0 1 UDP 2122252543 10.16.212.74 44090 typ host)): Received response; processing

STUN-CLIENT(kMAM|IP4:10.16.212.74:46958/UDP|IP4:10.16.212.74:44090/UDP(host(IP4:10.16.212.74:46958/UDP)|candidate:0 1 UDP 2122252543 10.16.212.74 44090 typ host)): nr_stun_process_error_response failed

STUN-CLIENT(kMAM|IP4:10.16.212.74:46958/UDP|IP4:10.16.212.74:44090/UDP(host(IP4:10.16.212.74:46958/UDP)|candidate:0 1 UDP 2122252543 10.16.212.74 44090 typ host)): Error processing response: Retry may be possible, stun error code 400.

... block above 7 times

STUN-CLIENT(kMAM|IP4:10.16.212.74:46958/UDP|IP4:10.16.212.74:44090/UDP(host(IP4:10.16.212.74:46958/UDP)|candidate:0 1 UDP 2122252543 10.16.212.74 44090 typ host)): Timed out

ICE-PEER(PC:{0a2c1cc7-e126-48d3-b5e1-9daf5d6f401f} <time> (id=23622320129 url=http://localhost:4000/):default)/CAND-PAIR(kMAM): setting pair to state FAILED: kMAM|IP4:10.16.212.74:46958/UDP|IP4:10.16.212.74:44090/UDP(host(IP4:10.16.212.74:46958/UDP)|candidate:0 1 UDP 2122252543 10.16.212.74 44090 typ host)

ICE-PEER(PC:{0a2c1cc7-e126-48d3-b5e1-9daf5d6f401f} <time> (id=23622320129 url=http://localhost:4000/):default)/STREAM(PC:{0a2c1cc7-e126-48d3-b5e1-9daf5d6f401f} <time> (id=23622320129 url=http://localhost:4000/) transport-id=transport_0 - 535cef18:724fdd891babdd9d2d8480c9af275f58)/COMP(1): All pairs are failed, and grace period has elapsed. Marking component as failed.

Technically resolves #32

Updates Bevy to 0.8 which requires bevy_ggrs 0.10 Removed patch specification for ggrs to update to 0.9.2

Updated serde_qs to 0.10 and winit to 0.26.1 (removing patch specifier) while I was there

I know this is blocked on releases of ggrs and bevy_ggrs but I was curious what would be required to get this demo working using bevy 0.9 . Once I got it working I thought I might as well open a PR in case it's useful in the future.

XRef https://github.com/johanhelsing/matchbox/issues/55

Adding complex new features like #64 is made more difficult because of mainly two issues in the code structure.

1. There are two versions of the WebRTC socket and all its components for two compile target (groups) - one for native and one for wasm. All work needs to be done twice and even if both code versions resemble each other in many ways there are also many differences

2. Most of the code lives in one huge file (per target) which is not too easy to understand - the code structure as it is now doesn't quite fit in my head and I find myself looping over and over through the code trying to understand how one thing affects the other and where the data is flowing. For example even after spending hours with it it's still not clear for me what is the main difference between handshake_offer and handshake_accept or the handling of PeerEvent::NewPeer and PeerEvent::Signal and why they are so similar and if the code can be easily deduplicated or not. Or what exactly is the exact purpose of all the different senders and receivers.

Ideally before starting some major refactoring work we can get rid of the separate code for wasm. Unfortunately webrtc-rs doesn't yet support wasm and it's not even planned but they opened an issue for that topic with a help wanted label suggesting that they are open to it: https://github.com/webrtc-rs/webrtc/issues/351

I would be motivated to have a go at it if you also would be looking forward to use this later in matchbox and if you agree that this could dramatically reduce or even eliminate our wasm-specific code.

Please let me know what you think

Exploring your suggestions in #63 regarding #25 I tried an alternative implementation.

The two main differences beside some fixes are:

1. It is possible to receive a packet and at the same time understand from which channel it came
2. I use vectors instead of tuples to prepare for a later extension of the feature for more than two data channels

I decided to open two PRs for both variants because I am not sure which one is better. I like the simplicity of #63 and I tried to keep it in this PR - it is still possible to simply use the send() and receive() methods to not have to worry about the big world of WebRTC at all and remain blissfully oblivious of the data channels used backstage.

If the library user would like to have more influence or information over how the packet is or was sent I added two methods:

• send_enhanced() that return or take a struct respectively where the user can request the packet to be sent via a certain channel (possibly there might be other settings later on but I can't think of any right now to be honest).
• receive_enhanced() where the user can see via which channel the packet was received

Of course there would be more convenient APIs if it would be a common usecase to open several data channels where each has its own specific settings and use cases but I love matchbox for its simplicity and this is I think the simplest API for simple use cases.

Please let me know what you think and if this is going more in a direction that is convenient for you as well.

The bevy_ggrs main branch has been fixed to work with Bevy 0.9, but needs currently unreleased changes in ggrs.

This means the ggrs-socket feature in this repo depends on an older ggrs version than bevy_ggrs.

After the next version of ggrs is released, we should update the dependency and the matchbox_demo example.

If you encounter this, a possible workaround is to apply a patch for ggrs:

Cargo.toml:

[dependencies]
bevy = "0.9"
matchbox_socket = {version = "0.4", features = ["ggrs-socket"]}
bevy_ggrs = {git = "https://github.com/gschup/bevy_ggrs"}

[patch.crates-io]
ggrs = {git = "https://github.com/gschup/ggrs"}

I tried following @johanhelsing's blog post series for extreme-bevy and got some success, however after a few seconds my clients randomly disconnect after a short lag spike, while my Chromium peer tells me the following:

Failed to send: JsValue(InvalidStateError: 
Failed to execute 'send' on 'RTCDataChannel':
RTCDataChannel.readyState is not 'open'

coming from here: https://github.com/johanhelsing/matchbox/blob/3f86e86f3df6c4bff6d7b3f1324177d936119635/matchbox_socket/src/webrtc_socket/wasm/message_loop.rs#L107

After some testing and consulting @gschup on Discord, I found out that this happens every time at least one of the two peers uses Firefox.

I tested the following configurations, all resulting in the error:

• Firefox versions:
  • stable 100.0
  • nightly 102.0a1
• setup:
  • two peers on same machine
  • two peers on two machines
• operating systems
  • Windows 10
  • macOS Monterey
• games
  • https://github.com/janhohenheim/extreme-bevy
    • My Cargo.toml has all git dependencies pinned to specific revisions, so this should be very reproducible
    • networking.rs
  • https://helsing.studio/box_game/ (live version)
  • https://gschup.github.io/bevy_ggrs_demo/ (live version)

untested:

• Firefox versions:
  • older than 100.0
• operating systems
  • linux
• setup
  • more than two peers