Hacker News Reader

Comment by jeroenhd | Hacker News Reader

I don't see why mDNS would be any less stable than UPnP. If anything, it should work better, as common advice (and these days even router defaults) is to disable UPnP. I'm sure the stack isn't tested as well (after all, the existing stack has been receiving patches for a decade) but if anything I'd expect the new stack to work better once the bugs are ironed out.

View on HN

Yeh, I don't think it's the tech choice that's the problem. It's the choice to change the tech that has caused this.

A clean rewrite of a wireless networking stack that does real-time synced audio streaming and device discovery on any users home WiFi (which is notoriously bad!) is a decision to face a lot of pain finding the edge cases that were previously fixed 10y ago.

And the decision, to not keep the old implementation around as fallback for the edgecases..

/v1/unbelievable/hubris/

UPnP is just a generic discovery+RPC service. The router toggle is just for whether it should expose a service to let apps request temporary port forwarding (mostly used by torrent clients and game servers). The advice to disable it is because that ability is considered undesirable, not because there's anything wrong with the protocol itself.

Sonos devices and apps used uPnP. The router was not involved.

The problem is probably more related to the cloud enshittification and using we sockets I guess.

The cloud integration is the main technical issue.

Rather than a UDP packet going to my speaker next to me in <1ms, it now requires an authenticated encrypted round trip to the other side of the world and back.

The mDNS is an implementation issue that could be resolved without such a significant, noticeable, irreversible effect on latency as with the cloud integration.

How does it work offline then ?

Reply on news.ycombinator.com