[samplonius]

I debate whether multicast has any use case in gaming.

When online gaming started, it was fairly common to send the entire world state to all clients. Multicast helps when you are sending the same data to everyone. but online gaming started, worlds were small (think Quake I level). However, this type of model does not scale as the world size increases, and eventually the world is too big to send everything to every client.

Plus, cheating. Sending the entire world state to every client, opens up cheating vectors. The trend has been for the game server to send only state that the particular client can actually see or needs. This limits the damage of what a compromised client can do. Plus, it allows the world size to scale up.

[derefr]

Don't picture a single multicast connection socket for all clients. Picture a multicast pub/sub topic model: each client would have a regular unicast socket to send to the server, but to receive, each client would subscribe to a set of server-multicast channels, one listener-socket per channel.

For each event, the server would find (or create) a multicast-socket channel that has only the correct subscribers, and push the message once over that multicast socket. The network would then do the job of making that message arrive on every client.

And, of course, you can separately encrypt each multicast channel[1], handing out keys over a regular 1:1 TCP+TLS "control" socket to the clients. (This would usually be merged with the client's unicast "send" socket.)

Guess what design I have just coincidentally described? Cable set-top-box pay-per-view! (The original kind, not the "over-the-top" access-on-demand kind which is effectively equivalent to Netflix.)

In legacy STB PPV, each movie stream chunk is an "event" as described above; each stream is separately encrypted; and each set-top-box gets a low-bandwidth TCP-like duplex control channel to the head office to request and receive keys for streams. People requesting the same movie at the same time get put into a queue and then bucketed on ~15min intervals; each bucket gets temporarily allocated a UHF band; and then a stream is broadcast over that band to everywhere that head-office reaches, injected on the line similarly to a local public-access cable TV channel, but only existing for two hours.

---

[1] If your clients are okay with their bandwidth being wasted, you can be a bit sloppier and get away with fewer (or even just one) multicast socket(s). Imagine a multiplayer game like Starcraft: you could push every player's update events to all players... encrypted with keys in a keybag whose owners are the people the event should be visible to. Clearing fog-of-war would literally involve the client performing an action that the server responds to by sending a key to decrypt previously-received opaque event data.

This matches the model of how, say, collaboration software treats group ACLs: being granted access to a new group means being given the key to decrypt the object-change-events within the global event stream that were relevant to that group.

[kbenson]

There's nothing preventing you from sharding the world state into multiple multicast streams which clients could access/subscribe to as needed. You would still get the benefit of not sending massively duplicated data, and additionally clients wouldn't be downloading large portions of world state that are either useless, an exploit vector (even if it just exploits the game), or both.

[Dylan16807]

Sending a fraction of the entire world state is still enormous for most non-FPS game types. It would benefit from multicast.

Also, map-hack-style cheating will always be common because of games that take the efficient rout, sending only inputs.