My goal: To write a program where any two computers on the same LAN see each other, and can talk directly to each other without any servers or accounts. Every client must be just as strong as every other client, and maintain their own list of which clients are online. (I plan on using computer hostnames hashed with IP addresses to keep entries unique).
My design: I want to get every client a list of every other client currently on the LAN. That means regular broadcast messages to all clients on the network, and timeout periods for clients so that the list is trimmed of offline clients.
My problem: That takes a toll on the network, to broadcast to every client there. If there are 2 client programs on a network with 300 computers, that is 298 computers that have no use for the packets they are receiving. Also I don’t know which port to use. In addition, network broadcasting is obsolete in IPV6, and I don’t want to structure this part of the code in a to-be-obsolete way.
My research: I could use IP Multicasting to send out signals to only interested clients (those running my program). Regularly sending signals out every 60 seconds shouldn’t be too wasteful if it isn’t going to any non-interested programs.
Source Specific Multicast is a bad choice for me because no one source can be established ahead of time. I would need to do either Sparse or Dense multicasting.
I just want to confirm that I am on track, that using Multicasting is the best possible protocol for keeping my clients on the same page.
Here is one last caveat. Let’s say all the wired clients are on a LAN which contains a wifi router, such that the wifi router runs a DHCP and packet routing service for just wifi enabled clients. What technique would be most reasonable to multicast across a network gap like this (and not all the way to the global internet)?
You’re on the right track with multicast for a peer to peer system without a central broker. Very expensive systems used in financial services for low latency messaging do exactly that to implement topic resolution and optionally the messaging itself.
However, take it from me, once you get out of the single VLAN scenario and need to traverse firewalls and routers then multicast becomes very brittle. It’s not that those devices don’t support multicast very well – they do. Nor is it that IGMP is a poorly thought out protocol – it’s not. It’s that the knowledge of how to set up multicast routes and maintain them seems to be the domain of only the most experienced network engineers.