On Thu, Apr 14, 2016 at 4:23 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 15/04/2016 04:54, Ted Lemon wrote: >> You should read the homenet naming and service discovery architecture >> document. :) >> >> On Thu, Apr 14, 2016 at 12:54 PM, Christopher Morrow < >> morrowc.lists@xxxxxxxxx> wrote: >> >>> >>> On Thu, Apr 14, 2016 at 12:32 PM, Phillip Hallam-Baker < >>> phill@xxxxxxxxxxxxxxx> wrote: >>> >>>> Going to unicast should help. Multicast configuration really doesn't >>>> work on a network with as many hubs and devices as mine has. >>>> >>> >>> multicast would work, if all the hubs/devices did multicast properly, >>> right? :) > > Really stupid devices do multicast properly because they are genuinely > transparent to layer 2. The annoying devices are the ones that pretend > to be layer 2 + layer 3 devices but are actually half-baked layer violation > devices. (To be specific, I have recently been burned by a layer 2/3 switch > that does not perform correct MLD snooping. And I agree that you have to be > in the 1% to diagnose that.) As a general rule, any time a network device attempts anything heuristic, it is going to get things wrong. The heuristic becomes a source of error. Which was why so many of the early NATs were so comically bad. They would attempt to patch up protocols like FTP, make a hash of it and break things. Sure, Homenet might solve some of these problems. But the reason for my 'screed' is that listening to folk in Buenos Aires, I think a lot of you are trying to build a network for yourselves and not a network that works for someone like Jeremy Clarkson. One of the rather more frustrating recent developments has been an understanding of 'usability' that comes down to 'don't give the user any information that might confuse them'. Windows and OSX both suffer from their own particular flavors of this approach. In networking it is the hub that is dropping the packets and not saying why or even mentioning the fact that it did so. >>> it's not clear that unicast works, if the problem you are trying to solve >>> is service-discovery... absent some registry of 'services' for your clients >>> to use, of course (which is the point of the mdns thingy). > > It seems to me that doing everything unicast makes life harder for no > reason. I don't know how we could make the Anima signaling work without > multicast, but we are restricting it strictly to link-local multicast. As another general rule, all protocols that rely on superfluous communication are bad protocols. Before talking on a network, a device should authenticate. Is the device going to authenticate with every other device on the network? Does anyone imagine that to be scalable? I have over a hundred devices on my network and in ten years time, I think that will be considered small. If we are serious about IoT then every socket, every lightswitch is a network device, thats another couple of hundred right there. Recourse to multicast is the network equivalent of suck it and see programming. Instead of having a concept of fault tolerant network control with failover, every device on the network is constantly yammering to the network as a whole just to tell people its there. When people do that, we call in a psychologist. In process control, networks are much quieter because the plant managers want to be able to tell why every packet on their network appeared. Noisy protocols that talk for the sake of talk are severely frowned on.