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.