@cpurdy Could you enlighten me on ARP and other broadcast/multicast protocols, for better network communication and less collision/congestion?
-I want to know if there is something that I am missing.
Do you have network issues? That's the first and most important question. And if you do, how do they appear, i.e. what symptoms show up?
I haven't worked directly with (i.e. implemented / consumed) ARP traffic, so I have to take a pass on that one. (ARP no relationship to ARPA i.e. ARPAnet, even though they were coincident.) ARP is an old protocol, so I'm sure it's very conservative by modern standards. It's low level ("link layer"), so you're not typically going to meet anyone who has ever had to interact with it, unless they build switch firmware etc.
I have a lot of experience with multicast protocols. I designed and implemented TCMP (see
https://xkcd.com/269/ 
) back in 2001, which was a mixed unicast/multicast protocol for server clustering. Relatively few things in the home use multicast and broadcast traffic, though. High throughput datagram protocols (e.g. multicast and broadcast) can be very destructive to other traffic on the network, because flow control is a hard thing to get right; it took us a few versions of TCMP to get it right. At any rate, you'll probably only have a tiny bit of multicast/broadcast/anycast traffic on your home network. Bonjour (Apple) uses a little bit, for example.
Most homes are probably more than sufficiently served with a gigabit wired network: The per port prices are very cheap, and it takes a lot of effort to chew through that much bandwidth, even with video streaming (I use Plex for example). Most protocols are on TCP/IP, which has exponential back-off on collision, so it auto modulates (this is "flow control") to deal with things like congestion. You can see some of the stats for packet loss etc. if you dive deep enough into your OS. The numbers of lost packets when connecting on a wired network at home should be tiny; connecting to services on the Internet will likely drive those numbers up, but those losses are almost certainly occurring outside of your home. Lost packets aren't a problem for TCP/IP; as long as anything at all is getting through, the protocol will adjust and not lose any data.
The biggest collision/congestion problems in the home tend to be related to WiFi, not wired Ethernet, and it's not usually a bandwidth problem as much as it is a distance/obstacle problem. WiFi signals degrade by the 3rd power with distance, and the higher the frequency, the more they degrade when going through floors and walls. Ideal WiFi connections are unobstructed line-of-sight, with relatively short distances. So the "mesh" WiFi networks (I like Deco by TPLink) are a pretty compelling choice, because you can sprinkle them strategically throughout a home or business, with Ethernet wired connections between the WiFi access points.
The other problem with WiFi is that everyone has it, so if you're in an apartment in New York, you'll see 400 other WiFis, and you can imagine how much noise there is on those channels. I use a product called WiFi scanner (e.g. runs on MacOS) that shows me what WiFis are using what channels, and various SNR data, so I can configure each access point to use an optimal channel. WiFi access points supposedly can do this all themselves, but they used to be very bad at it; at some point, it's going to be better to trust them to self-configure than to manually configure them, but I'm not sure if we have already passed that point or not.
Fortunately, when it comes to music transfer on a network, it's such a low-bandwidth use case that it's hard to imagine any issues. I use a RAID-5 NAS (Gigabit Ethernet, directly into one of my backbone switches) for storage, and an old Mac Pro (the "trashcan") to run Plex. The FLAC files are tiny -- maybe on the order of 40MB per song, so call it 10MB/minute. A gigabit network can easily handle 100MB/s, so 10MB/m is 3 orders of magnitude smaller, i.e. it's a miniscule amount of traffic. Even with a hop from the NAS to the Plex server, and another hop or two from the Plex server to some WiFi access point, and another hop to my phone, it's still a tiny rounding error of the available bandwidth on the network. And since players tend to buffer several minutes of music (at a minimum), even severe congestion
shouldn't pose any problems.
... but if you're happy with it, that's what matters. Modern switches do a good job not sending stuff where it's not needed. And remember that when a lot of these protocols were created, 10Mb/s Ethernet wasn't even around yet (if you could imagine anything slower than that!)
