Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix typos in webrct_signalling/README.md #750

Merged
merged 1 commit into from
Jun 15, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 14 additions & 14 deletions networking/webrtc_signaling/README.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
# A WebSocket signaling server/client for WebRTC.

This demo is devided in 4 parts:
This demo divided into 4 parts:

- The `server` folder contains the signaling server implementation written in GDScript (so it can be run by a game server running Godot)
- The `server_node` folder contains the signaling server implementation written in Node.js (if you don't plan to run a game server but only match-making).
- The `client` part contains the client implementation in GDScript.
- Itself divided into raw protocol and `WebRTCMultiplayer` handling.
- The `server_node` folder contains the signaling server implementation written in Node.js (in case you dont want to run a godot game server).
- The `client` folder contains the client implementation in GDScript.
- It handles both the protocol and `WebRTCMultiplayer` separately.
- The `demo` contains a small app that uses it.

**NOTE**: You must extract the [latest version](https://github.com/godotengine/webrtc-native/releases) of the WebRTC GDNative plugin in the project folder to run from desktop.
**NOTE**: You must extract the [latest version](https://github.com/godotengine/webrtc-native/releases) of the WebRTC GDNative plugin in the project folder to run on a desktop.

Language: GDScript

Expand All @@ -18,26 +18,26 @@ Check out this demo on the asset library: https://godotengine.org/asset-library/

## Protocol

The protocol is text based, and composed by a command and possibly multiple payload arguments, each separated by a new line.
The protocol is text based, which is composed of a command and possibly multiple payload arguments, each separated by a new line.

Messages without payload must still end with a newline and are the following:

- `J: ` (or `J: <ROOM>`), must be sent by client immediately after connection to get a lobby assigned or join a known one.
This messages is also sent by server back to the client to notify assigned lobby, or simply a successful join.
- `I: <ID>`, sent by server to identify the client when it joins a room.
- `N: <ID>`, sent by server to notify new peers in the same lobby.
- `D: <ID>`, sent by server to notify when a peer in the same lobby disconnects.
- `S: `, sent by client to seal the lobby (only the client that created it is allowed to seal a lobby).
- `J: ` (or `J: <ROOM>`), must be sent by the client immediately after connecting to get a lobby assigned or join a known one.
These messages are from the server back to the client to notify the client of the assigned lobby, or simply of a successful join.
- `I: <ID>`, sent by the server to identify the client when it joins a room.
- `N: <ID>`, sent by the server to notify new peers in the same lobby.
- `D: <ID>`, sent by the server to notify when a peer in the same lobby disconnects.
- `S: `, sent by a client to seal the lobby (only the client that created it is allowed to seal a lobby).

When a lobby is sealed, no new client will be able to join, and the lobby will be destroyed (and clients disconnected) after 10 seconds.
When a lobby is sealed, new clients will be unable to join, and the lobby will be destroyed (and clients disconnected) after 10 seconds.

Messages with payload (used to transfer WebRTC parameters) are:

- `O: <ID>`, used to send an offer.
- `A: <ID>`, used to send an answer.
- `C: <ID>`, used to send a candidate.

When sending the parameter, a client will set `<ID>` as the destination peer, the server will replace it with the id of the sending peer, and rely it to the proper destination.
When sending the parameter, a client will set `<ID>` as the destination peer, the server will replace it with the id of the sending peer, then relay it to the proper destination.

## Screenshots

Expand Down