WebRTC for games

[cdsmith]

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]

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]

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

[nomeata]

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

[cdsmith]

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 Quota, DOS protection, or verification for the game relay server #384 and Monitoring for CodeWorld game server #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]

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.