P2P? STUN? TURN? ICE? Signaling? Relay?

So when I was setting up WebRTC for AirHockey, a whole pile of vocabulary showed up. I want to document a short version of each to remind future me, in case there is ever a chance I use this again:

• P2P (peer-to-peer): a direct connection between the two players, with no server sitting in the middle. Lowest latency, which is exactly what a fast game wants.
• Signaling: WebRTC does not help two peers find each other, so you build a signaling channel (I used WebSockets, which we already had) to swap the "here is how to reach me" info before the real connection opens.
• STUN: a lightweight server that tells a peer its own public address, since almost everyone sits behind a router doing NAT, the trick that lets many devices share one public IP address.
• TURN: a relay server for when a direct connection just refuses to happen. Traffic goes through it instead. It is not our websockets, and you pay for the bandwidth.
• ICE: the referee that gathers every possible route (local, STUN, TURN) and tries them until one sticks.
• Relay: the TURN path, the plan B where the server passes the packets along. This is WebRTC's own relay, not the WebSocket fallback below.

The flow ends up being: both players hit the signaling server, ICE collects candidates, and it attempts a direct P2P link first. If NAT or a firewall blocks that, it falls back to relaying through TURN.

And if WebRTC gives up entirely? I kept a WebSocket fallback, where the game just relays its state through my own server instead. Slower, but playable beats broken.

To future me: if you ever have to wire this up again, hope this jogs the memory and actually helps.