Essentially they replaced the 15 year old, and incredibly robust network based on UPnP, with a new system using mDNS+HTTP+Websockets. And at the same time stuck their cloud in the loop for connecting to third party music services.
It's resulted in a much more fragile networking stack, far more prone to incompatibilities with users WiFi configurations. Which due to being so much heavier, some of their older hardware may struggle with. And that's all before you consider the UX changes in the app, and the missing functionality (how do you release a forced upgrade before finishing all old, and essential, functionality?!)
I assume that they have started removing some/all of the old code from the speakers which makes the old app incompatible.
I can confirm, last night my internet was not working, and a sonos speaker started randomly playing an alarm. I tried using the app to disable it but it requires the internet to manage your local speakers. I don't recall this being the case with the early version of the apps.
mDNS is probably the way to go, UPnP is de-facto deprecated (and should be, it's awful) while mDNS is pretty well supported and tends to "just work" most of the time IME. That being said, HTTP and Websockets are a freaking horrible choice for an embedded system. SO MUCH TEXT PROCESSING. The poor little MCUs probably struggle to do that in any reasonable amount of time. Not to mention you probably want to make use of RTP/RFC3550 to get priority for realtime-sensitive traffic (maybe this is less relevant over a LAN, but I'd still at least test it in a few scenarios), something websockets/HTTP are incapable of.
oh wow, SOAP/XML is somehow worse. Websocket is a binary protocol, but you're probably slinging HTTP reqs or JSON over it. The downside is the protocol itself is stateful so you have the overhead of doing an HTTP upgrade + managing a stateful TCP connection. Idk why you would use either of those technologies for LAN-only transports, though I could see it being the best option for talking to the mothership.
I guess that means it's entirely engineering practice or maturity. That just makes me sad :(
I was hoping for something a lot more silly like NASA tapping over the Moon landing tapes. A sort of "We cannot get the old app back because we don't know where it is".
Instead it is the usual case of development in search of a new horizon.
They made shareholders very happy by replacing all those expensive in-house employees with cheap outsourced labour. Sadly, nobody knew that there was more than one type of coding bootcamp. That's how they ended up with the React crew for a bare-metal job.
> replacing all those expensive in-house employees with cheap outsourced labour. ... they ended up with the React crew for a bare-metal job
This seems likely, but I have yet to see real evidence of this theory, such as an insider or one of those "replaced, expensive, former in-house employees" speaking.
> My reading of how mDNS works is that it should suffer from similar problems to SSDP on routers that can't broadcast/multicast between radios
This smells of someone who is not a network engineer. mDNS works fine, it has known ways to route it across broadcast domains, and actually, way more products out of the box can "reflect" mDNS across VLANs than SSDP. What on earth does that have to do with broadcasting "between radios"?.
> This is because the speakers all know where each other are on the local network (thanks to SSDP),
"[...] far more prone to incompatibilities with users WiFi configurations [...]" <- Exactly this! With my Unifi gear, all the configurations that had to be tried out and tested were driving me crazy. From Multicast Filtering (IGMP Snooping), Multicast Enhancment (IGMPv3), Broadcast Contols, mDNS to even the fucking Spanning Tree Protocol on the Switches (STP vs RSTP). How is this plug and play? How are other users even getting anything to work when it comes to multi room and speakers being on seperate APs?!
I've had what I think is this exact problem and it was solved by doing a factory reset on the Ubiquiti controller (I have a pre-production DreamMachine UDM). It only happened once and it was most certainly from a firmware update that corrupted some state/config on the system, probably in iptables forward rules if I had to make an uneducated guess.
I have all speakers on Ethernet to start with. But I also had to put them into the same vlan as my phone, as I could not come up with a firewall config to span multiple vlans. It’s tricky.
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.
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.
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.
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.
It's sad to hear that the new app encrypts everything.
A long time ago I worked on hacking airplay support for sonos speakers and it wouldn't have been possible without inspecting a lot of plaintext wireshark traffic.
Essentially they replaced the 15 year old, and incredibly robust network based on UPnP, with a new system using mDNS+HTTP+Websockets. And at the same time stuck their cloud in the loop for connecting to third party music services.
It's resulted in a much more fragile networking stack, far more prone to incompatibilities with users WiFi configurations. Which due to being so much heavier, some of their older hardware may struggle with. And that's all before you consider the UX changes in the app, and the missing functionality (how do you release a forced upgrade before finishing all old, and essential, functionality?!)
I assume that they have started removing some/all of the old code from the speakers which makes the old app incompatible.