Concept / Background Reading

[samouri]

Summary
Straight up UDP is impossible in browsers, yet essential for any highly real time applications.
For a real-time game, TCP is unacceptable unless in ideal network conditions (100ms latency 0% packet loss).

There is a protocol called WebRTC meant for p2p connections between browsers. It was designed for things like video/voice chat, file transfer, etc and requires at least a signalling server (STUN) in order to connect peers. The super interesting bit here is that WebRTC allows for the creation of data channels. These channels behave similarly to websockets, and are allowed to be configured to have unordered and unreliable packet delivery.

The protocol has been designed purely for the p2p case and implementing a server/client architecture though it is incredibly awkward (the libs are pretty awkward even for the usecase they were built for).

I think it should be possible to build an api on top of WebRTC libs that would let us create an easy to use UDP-like connection in a client/server model.

Background Reading

• Peering though the WebRTC Fog: Background on the complexities of the standard.
• HumbleNet: C based lib that works with WebRTC and gets compiled via emscripten
• SimplePeer: the best looking lib for radically simplifying WebRTC usage. Also works in Node.js. Currently supports only a single customizable data-channel.
  • SimplePeer Multiplex Support: approved by maintainer. Just awaiting a PR.
• Deterministic Lockstep: Gaffer On Games discussing deterministic lockstep and just how much better UDP is than TCP.
• TCP vs. UDP: Gaffer on Games discussing TCP vs. UDP at length. The interesting bit is that mixing UDP and TCP can induce packet loss for UDP. ew.
• Multiplayer Networking: also this one. Valve covering the basics for how to handle latency in a game.

[zachlite]

Background on client server networking mechanics
http://www.gabrielgambetta.com/client-server-game-architecture.html

[samouri]

@zachlite: hows the udpeer research going?