[mananaysiempre]

> abandoning their reliable UPnP (Universal Plug and Play) system for device discovery in favor of mDNS

I don’t know about that part. UPnP is exactly the HTTP-abusing XML-laden layer-spanning horrorshow you expect from 2000s Microsoft where it was mainly supported, mDNS is a fairly compact and neat set of independent extensions to preexisting Internet protocols born during Apple’s short period of flirting with open standards. In a greenfield project, you’d need to show me some really impressive tooling to make me choose UPnP, because five minutes with the specs are enough to tell implementing or debugging the thing is going to be a nightmare.

(No experience with Sonos or their implementation of either.)

[stephen_g]

I had the same reaction, all the other parts of the parent comment sound bad but switching to mDNS seems like the one that should have been an improvement or at least neutral...

[packetlost]

I'll second this. UPnP is wisely considered a bad idea and a security liability. mDNS usually just works and has been the foundation for several successful consumer platforms including Chromecast

[throwway120385]

As someone who has used mDNS professionally, it did indeed just work.

[mananaysiempre]

> UPnP is [...] a security liability

UPnP generally or just UPnP IGD (frequently referred to as “UPnP” in consumer router UIs)? I’d imagine the primary reasons a smart speaker would want to use UPnP are largely unrelated to punching holes in firewalls and NATs (what IGD is about). And however distasteful RPC over XML over jury-rigged HTTP over IP multicast may be, it’s hardly inevitable that it must create a security problem.

Even if we’re speaking about holes, though, I feel like I must object to the broad description of that function as a security vulnerability, as any instance of that moves us that much farther away from a true peer-to-peer Internet.

[Spivak]

Where are you getting reliable mDNS? I love the protocol on my own devices but good lord the Google Home ecosystem is terrible. Playing audio through multiple speakers at all, forget getting them in sync, is an exercise in frustration. And when I check by scanning mDNS it's always hung getting no responses from devices I know are there.

The literal Chromecast itself seems to be exceptional device that just works.

[ZeroCool2u]

That's interesting, my google home devices always play audio in sync and seem to just work.

[sgt]

Been using mDNS for years in the Apple ecosystem. Never had issues, except maybe 5-6 years ago with AirDrop but been rock stable since. Using airdropping, sharing screens, printing, audio, all kinds.

[btreecat]

You might have an issue with your router

[eddythompson80]

I'm guessing people commenting on UPnP vs mDNS implementation are mostly referencing this post https://www.linkedin.com/pulse/what-happened-sonos-app-techn...

But it wasn't just a move from UPnP to mDNS with everything else remaining the same. They also moved to HTTP/WebSocket instead of UPnP eventing, added encryption.

While most complaints in this thread about the app all say "it's sluggish", with the initial release of S2 many had their systems that worked perfectly fine with S1 undiscoverable with S2. At the time all the advice on Sonos forums, Reddit, etc was "First check your router and make sure mDNS isn't disabled". Which caused a lot of people to have a kneejerk reaction of "wtf is this mDNS shit and what was wrong with the "old reliable UPnP"

[jauntywundrkind]

HTTP/WebSocket relies on a stateful connection! Man that strikes me as so not smart!

Comedically, UPnP was also HTTP, but not as stateful as websockets. Often httpu, http over UDP. And for service discovery, httpu over multicast, pretty much like mdns. I'm surprised that s2 would have broken, given that I'd expect s1 to also need multicast. Maybe Sonos setup a pinhole router via upnp-igd, so devices could talk to each other inside the network, even if multicast was off? It's be interesting to know if any upnp-igd rules were created in s1.