Something I just thought of recently, if you have a lot of clients connected in your LAN network (say over 100), would sending your packets to the broadcast IP (assuming it's not blocked) be more efficient vs having each client send packets to every other?
I would assume so because each client only talks to and listens from one IP, rather than having to iterate through all other clients IP addresses, but I'd love to hear your thoughts.
If every client sends packets to every other client, then the number of packets scale by N-squared, which at 100 clients is already way past what you'd want to see. This is one of many reasons why peer-to-peer connected mesh networking topologies don't work for many-player games on the internet.
If every client broadcasts their state (which only works on LAN, of course,) then the number of packets only scales by N, which is much better, BUT if there's a lot of non-playing client computers on the same network, all those computers/links will also see all those broadcasts, which may not be desired.
Over the general internet, the model where each client sends a small packet to a central location (server) and the central location sends a aggregated packet to each client is the most network-efficient. On a LAN, you can do even better with one machine being the host, all clients sending their inputs directly to the host (not broadcast,) and the host broadcasting one packet with all the inputs for that tick to all the clients. It's the best of both worlds, in this case.
On 2/22/2019 at 11:56 AM, hplus0603 said:On a LAN, you can do even better with one machine being the host, all clients sending their inputs directly to the host (not broadcast,) and the host broadcasting one packet with all the inputs for that tick to all the clients. It's the best of both worlds, in this case.
Wouldn't the data be delivered at least twice? One to the server and the other to the rest of the clients? Compared to the broadcast IP, the packets are automatically broadcast to other clients.
There are two things that matter on a LAN: Number of packets, and total size of data.
When you broadcast your state from each client, you send the state of each client, to each client. The number of packets per frame per link is N (one from each client, plus the one upstream,) and across all links it is then N-squared, where N is the number of clients. When each client sends to the host, and the host broadcasts to all clients, the number of packets per link is 2, one upstream and one received, and the total number of packets across all links is 3*N, each client would send and receive 2 packets, and the server would receive N but send 1 packet.
The traditional client/server networking model would use about 4*N packets, but each client would only send and receive 2 packets, and the server would receive N incoming and send N outgoing packets.
Because each client needs the state of all other clients, you always get N-squared data growth no matter what, until you implement a smart server with visibility/importance filtering.
Btw, this is also why peer-to-peer topologies over the internet aren't all that efficient compared to client/server, because the packet count grows by n-squared, not just the total data size in this case, too.
That makes sense. I wasn't thinking what the routers need to do to broadcast the packets.
