search

google / codeworld

Educational computer programming environment using Haskell
http://code.world
Apache License 2.0
1.24k stars 193 forks source link

WebRTC for games #391

Open cdsmith opened 7 years ago

cdsmith commented 7 years ago

The game API may benefit from WebRTC when it's available on the client. In particular, it's often possible for WebRTC clients to communicate peer-to-peer after the initial signaling. The main advantage I hope to gain is not in latency, but in reducing the impact on a shared message relay, in the case where some student game "goes viral".

We do still need reliable delivery, so we can't gain the latency advantages of an unreliable transport, and WebRTC's streaming features are less appealing. (One could imagine playing some tricks where out of order delivery is exploited but dropped packets are still re-requested, so events are applied to the timeline as they arrive, but not committed until the stream is ready. But that sounds complicated...)

cdsmith commented 7 years ago

I've looked into this further in the background, but not done any new development. I believe this is absolutely the way to go. It's a fairly sizable project, though, as it means substantial changes to the game protocol. Advantages include:

  1. Replacing the custom game server with a hosted scalable system like XirSys.
  2. Avoiding the need to relay about 85% of traffic at all, because it can be routed peer-to-peer.
  3. Reducing the latency of the 85% of traffic that is peer-to-peer, particularly given that significant use cases involve multiple players on the same local network in a school, home, etc.
  4. Using a reliable out-of-order transport, to avoid TCP pipeline stalls.

Note that #378 is a prerequisite, since peer-to-peer communication has no server to facilitate communication.

cdsmith commented 7 years ago

Okay, looks like WebRTC is still unsupported on Safari. Until that changes, this isn't an option. :(

nomeata commented 7 years ago

I had looked into WebRTC for similar projects in the past, and always concluded that we are not there yet.

cdsmith commented 7 years ago

I'm thinking more about this. Some points worth noting:

  1. There is a polyfill of sorts for WebRTC on Safari (which requires installing a browser extension). See https://github.com/Temasys/AdapterJS
  2. The recent change to client-side timestamps means there's basically no interesting logic in the game server after the game session is established; it's just a pure message relay.
  3. The session establishment is less latency-critical, and could be migrated into the web server with a database back end. This would ease scaling, as well.
  4. Making this change would help massively with #384 and #390 (monitoring and security for the relay).

On the other hand, this would pose challenges for #404 and #380, since there's no good place to keep a canonical event log. One could imagine solutions (each client keeps its messages so it can retransmit them when asked; or there's a dedicated message recorder that joins all sessions) but they sound unappealing. That said, the prospect of offloading administration of an open message relay on the internet is worth some sacrifices.

cdsmith commented 5 years ago

Just a note that there's apparently a free STUN/TURN server at http://numb.viagenie.ca/ That sounds too good to be true, so there must be some kind of catch! But, it's worth looking into if we go this route.