0
\$\begingroup\$

I'm currently working on a fast-paced multiplayer sports game using Godot. The players' movements and actions are already being synchronized with WebSockets and Channels using a Node.js server. I now want to replace (part of) the WebSocket communication and synchronization between the clients by WebRTC to lower latency. I have been looking at this demo project by Godot as I think it may provide what I need.

However, I'm a bit confused about how to proceed and I have two questions based on the assumed knowledge I currently have:

  1. Can I re-use the same WebSocket Channel to send WebRTC messages or do I need to create a separate WebRTC Channel for that?
  2. How do I know the "address" of other players that I want to send WebRTC messages to? Should I get their id from the channel or use an IP address, or how does that generally work?

If possible, please also let me know whether some my assumptions are wrong and why.

PS. I wanted to add the webrtc tag to this question but it does not exist yet and I don't have enough reputation to add it. If there is anyone with enough reputation to add it that would be great.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I suggest reviewing when to add a new tag to the system and posting a request on GDSE Meta explaining the need for the tag & offering an initial usage excerpt. While we do have a few webrtc questions, I'm not familiar enough to judge how niche webrtc is or if it's effectively covered by existing tags. \$\endgroup\$
    – Pikalek
    Dec 29, 2022 at 16:18

1 Answer 1

1
\$\begingroup\$
  1. You can not, as far as I'm aware, re-use the same WebSocket Channel to send WebRTC messages. WebSockets are really just a persistent TCP based connection between client/server that allow for bi-directional communication. Infact, if you look at what a WebSocket connection is under the hood - it actually connects as a raw HTTP connection and then passes an upgrade header that allows it to transition to a websocket. WebRTC is different and allows for different "modes" in its channels (that correspond to tcp-like or udp-like) which WebSockets just don't support. this answer on stack overflow does a good job of quickly breaking down what these modes are.

  2. This is the hardest part of WebRTC. Due to Network Address Translation p2p connections are quite difficult. In some cases they are entirely impossible. You've probably seen terms like STUN, TURN, and ICE thrown around when talking about WebRTC. These protocols are what enable devices behind NAT to communicate with each other either directly, or through a coordinating server. AnyConnect has a really good intro to how these things work and links to all the necessary RFCs. Essentially, this means that to allow peers to discover each other you need to run a service that lets them do that (STUN). In some cases, where they can't directly establish communication, you can optionally provide a service that relays information between the two (TURN).

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .