Build Failure on rustc 1.45.2 stable channel

[ssnover]

Describe the bug

   Compiling ssdp v0.7.0
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/ssnover/.cargo/registry/src/github.com-1ecc6299db9ec823/ssdp-0.7.0/src/lib.rs:2:1
  |
2 | #![feature(ip)]
  | ^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `ssdp`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

To Reproduce Steps to reproduce the behavior:

1. Switch compiler to stable.
2. Go to root of repo and run cargo build.

Expected behavior Successful build on stable.

It looks like the ssdp crate itself requires a nightly compiler to build. I've had success with using mdns for discovery use cases, unfortunately it doesn't look like the Hue Bridge supports MDNS (based on keeping an eye on my Wireshark window for a couple minutes). It looks like the ssdp crate is no longer maintained, since it hasn't seen an update in 2 years, but there are other crates with more recent updates like ssdp-client if you'd be open to switching the dependency out.

I could spend some time this weekend trying to prototype with a different SSDP client and see if I can get it working.

[ssnover]

Here's a quick prototype I threw together, notably it requires making the API async: https://gist.github.com/ssnover95/5877fef6b81dc5d8c16ab7518488aa00

Console Output:

SearchResponse { location: "http://192.168.1.7:80/description.xml", st: RootDevice, usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f::upnp:rootdevice", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: UUID("2f402f80-da50-11e1-9b23-ecb5fa0ea38f"), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: URN(Device("schemas-upnp-org", "basic", 1)), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: RootDevice, usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f::upnp:rootdevice", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: UUID("2f402f80-da50-11e1-9b23-ecb5fa0ea38f"), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }
SearchResponse { location: "http://192.168.1.7:80/description.xml", st: URN(Device("schemas-upnp-org", "basic", 1)), usn: "uuid:2f402f80-da50-11e1-9b23-ecb5fa0ea38f", server: "Hue/1.0 UPnP/1.0 IpBridge/1.40.0" }

[ssnover]

Upon doing some further research, it looks like the ssdp package uses an unstable feature on Ipv6Addr, is_global(). This was very close to being stabilized earlier this year, but there were some concerns with some of the other APIs being stabilized along with it. Here's the tracking issue: https://github.com/rust-lang/rust/issues/27709 And the PR stabilizing the API: https://github.com/rust-lang/rust/pull/66584

I suspect it's not really worth subbing out the dependency for discovery over it, especially if it could be fixed in an upstream crate at some point in the near future.

[finnkauski]

I think SSDP has caused me quite a lot of grief. I'd imagine a good way to letting it build is to use a feature gate and have SSDP based discovery features be opt-out for end users wanting to build on stable?

If there's other more convenient and well maintained projects out there doing the job, I would be happy to switch.

[ssnover]

Unfortunately, ssdp-client doesn't nicely expose the IpAddr like ssdp does. You can see the representation of the SearchResponse that I debug printed to my terminal output includes location. Perhaps they'd be willing to add an API which parses the SocketAddr from that field and returns it.

[finnkauski]

You could parse the location as a path or a URI, I can't remember which one would be more convenient. This struct here https://docs.rs/http/0.2.1/http/uri/struct.Uri.html for example implements a TryFrom trait which allows you to parse strings into a URI and then we can extract the IP or we could use https://docs.rs/url/2.1.1/url/struct.Url.html. Given this is done in a very limited set of scenarios / times it won't impact our performance or much of anything except adds an extra dependency.