Skip to content

Commit

Permalink
Merge pull request #169 from garryod/docs-0.6
Browse files Browse the repository at this point in the history
Docs updates ahead of 0.6
  • Loading branch information
johanhelsing authored Mar 31, 2023
2 parents d7696ad + 6669e19 commit 06ced46
Show file tree
Hide file tree
Showing 3 changed files with 32 additions and 9 deletions.
25 changes: 16 additions & 9 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# [![Matchbox](matchbox_logo.png)](https://github.com/johanhelsing/matchbox)
# [![Matchbox](https://raw.githubusercontent.com/johanhelsing/matchbox/main/images/matchbox_logo.png)](https://github.com/johanhelsing/matchbox)

[![crates.io](https://img.shields.io/crates/v/matchbox_socket.svg)](https://crates.io/crates/matchbox_socket)
![MIT/Apache 2.0](https://img.shields.io/badge/license-MIT%2FApache-blue.svg)
Expand All @@ -10,15 +10,20 @@ Painless peer-to-peer WebRTC networking for rust's native and wasm applications.
The goal of the Matchbox project is to enable udp-like, unordered, unreliable
p2p connections in web browsers or native to facilitate low-latency multiplayer games.

- [Introductory blog post](https://johanhelsing.studio/posts/introducing-matchbox)
| Channel | Ordered | Unordered |
| ---------- | ------- | --------- |
| Reliable | ✓ | ✓ |
| Unreliable | ✓ | ✓ |

- [Tutorial for usage with Bevy and GGRS](https://johanhelsing.studio/posts/extreme-bevy)

The Matchbox project contains:

- A socket abstraction, [matchbox_socket](https://github.com/johanhelsing/matchbox/tree/main/matchbox_socket)
- With a feature, `ggrs` for providing a [ggrs](https://github.com/gschup/ggrs) compatible socket.
- A tiny signaling server, [matchbox_server](https://github.com/johanhelsing/matchbox/tree/main/matchbox_server). Written in rust, uses only a couple of megabytes of memory. Also available as a docker image. Compatible with all demos.
- A signaling server API, [matchbox_signaling](https://github.com/johanhelsing/matchbox/tree/main/matchbox_signaling). For DIY signaling servers and hookable callbacks, this may be useful if you plan a complicated matchmaking procedure.
- [matchbox_socket](https://github.com/johanhelsing/matchbox/tree/main/matchbox_socket): A socket abstraction for Wasm or Native, with:
- `ggrs`: A feature providing a [ggrs](https://github.com/gschup/ggrs) compatible socket.
- [bevy_matchbox](https://github.com/johanhelsing/matchbox/tree/main/bevy_matchbox): A `matchbox_socket` integration for the [Bevy](https://bevyengine.org/) game engine
- [matchbox_signaling](https://github.com/johanhelsing/matchbox/tree/main/matchbox_signaling): A signaling server library, with ready to use examples
- [matchbox_server](https://github.com/johanhelsing/matchbox/tree/main/matchbox_server): A ready to use full-mesh signalling server

## Examples

Expand All @@ -29,20 +34,22 @@ The Matchbox project contains:

## How it works

![Connection](https://raw.githubusercontent.com/johanhelsing/matchbox/main/images/connection.excalidraw.svg)

WebRTC allows direct connections between peers, but in order to establish those connections, some kind of signaling service is needed. `matchbox_server` is such a service. Once the connections are established, however, data will flow directly between peers, and no traffic will go through the signaling server.

The signaling service needs to run somewhere all clients can reach it over http or https connections. In production, this usually means the public internet.

When a client wants to join a p2p (mesh) network, it connects to the signaling service. The signaling server then notifies the peers that have already connected about the new peer (sends a `NewPeer` event).

Peers then negotiate a connection through the signaling server. The initiator sends an "offer" and the recipient responds with an "answer." Once peers have enough information relayed, a WebRTCPeerConnection is established for each peer, which comes with a data channel.
Peers then negotiate a connection through the signaling server. The initiator sends an "offer" and the recipient responds with an "answer." Once peers have enough information relayed, a [RTCPeerConnection](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection) is established for each peer, which comes with one or more data channels.

All of this, however, is hidden from rust application code. All you will need to do on the client side, is:

- Create a new socket, and give it a signaling server url
- `.await` the message loop future that processes new messages.
- If you are using Bevy, it can be spawned as a Bevy io task (see the [`bevy_ggrs`](examples/bevy_ggrs/) example).
- If you are using WASM, `wasm-bindgen-futures` can help (see the [`simple`](examples/simple/)).
- If you are using [Bevy](https://bevyengine.org), this is done automatically by `bevy_matchbox` (see the [`bevy_ggrs`](examples/bevy_ggrs/) example).
- Otherwise, if you are using WASM, `wasm-bindgen-futures` can help (see the [`simple`](examples/simple/)).
- Alternatively, the future can be polled manually, i.e. once per frame.

You can hook into the lifecycle of your socket through the socket's API, such as connection state changes. Similarly, you can send packets to peers using the socket through a simple, non-blocking method.
Expand Down
16 changes: 16 additions & 0 deletions images/connection.excalidraw.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
File renamed without changes

0 comments on commit 06ced46

Please sign in to comment.