astrohq / astro-dnssd Goto Github PK

I am trying to run the examples on a Linux distro:

$ uname -a
Linux [HOSTNAME] 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Setup starting from c80301a:

$ sudo apt-get install libavahi-compat-libdnssd-dev libavahi-compat-libdnssd1  # apt search libavahi-compat

Output:

$ cargo r --example browse
[2020-09-07T17:16:28Z INFO  browse] Starting browser...
*** WARNING *** The program 'browse' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/proje
cts/avahi-compat.html>
<END>

$ cargo r --example register
Registering service...
*** WARNING *** The program 'register' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
<END>

$ avahi-browse -a | grep MyRustService
+ enp7s0 IPv4 MyRustService                                 Web Site             local
+     lo IPv4 MyRustService                                 Web Site             local

The warning seems harmless, and I can confirm the service was actually registered using avahi-browse. But I expect log output from the callbacks like I get on MacOS. Otherwise the browse binary is unable to interact with the discovered hosts. See MacOS output from browse:

macos$ cargo r --bin browse
[2020-09-07T17:19:49Z INFO  browse] Starting browser...
[2020-09-07T17:19:51Z INFO  browse] Added: if: 8 name: MyRustService type: _http._tcp. domain: local.
[2020-09-07T17:19:51Z TRACE astro_dnssd::browser] Got TXT: TXTHash { data: [11, 115, 116, 97, 116, 117, 115, 61, 111, 112, 101, 110] }
[2020-09-07T17:19:51Z TRACE astro_dnssd::browser] MyRustService._http._tcp.local. - [HOSTNAME].local. service resolved
[2020-09-07T17:19:51Z INFO  browse] Addr: 10.128.162.203:2048
[2020-09-07T17:19:51Z INFO  browse] Addr: [fe80::f2:3585:957:c9b3]:2048
[2020-09-07T17:19:51Z INFO  browse] Resolved service: ResolvedService { full_name: "MyRustService._http._tcp.local.", hostname: "[HOSTNAME].local.", port: 2048, txt_record: Some(TXTHash { data: [11, 115, 116, 97, 116, 117, 115, 61, 111, 112, 101, 110] }), interface_index: 8 } status: Ok(Some([111, 112, 101, 110]))

Thanks for the crate!

I'm using an example derived from the repo's example.

I publish a service using (both with and without the with_domain():

    let mut service = DNSServiceBuilder::new("_rust._tcp")
        .with_name("astro-dnssd")
        .with_domain("local")
        .with_port(8080)
        .with_txt_record(txt)
        .build()
        .unwrap();

And I attempt to browse it using:

    let mut browser = ServiceBrowserBuilder::new(&kind[..])
        .with_domain(&domain)
        .build();

If I omit with_domain from both publisher and browser, it works.

If I add it to the publisher and omit it from the browser, it works.

"it works" meaning, the browser discovers the service:

Browser has data!
Added: interface: 4 name: astro-dnssd type: _rust._tcp. domain: local.

NOTE The regtype and domain both include trailing periods

I've tried various combinations of local (and local.) for the domain but I'm unable to filter the browser by domain.

I'm using the example's:

    let _result = browser.start(|result| match result {
        Ok(service) => { .. }
        Err(e) => println!("Error: {:?}", e),

And the Err branch is triggered with:

Error: ServiceError(-65537)

dns-sd.h has error constants we should map into a rust enum to better understand errors.

Currently resolve() on Service could possibly return an empty vector, we should treat that as an error if it can even happen.

See enormous amount of these in console:
2020-07-24 11:11:52.085719-0400 Project Blue[1321:345925] dnssd_clientstub DNSServiceProcessResult called with NULL DNSServiceRef

Likely needing to do some checks in processing results.

Would be useful for anything wanting to immediately use a service to have a simple single call to resolve the service info & the IP addresses available.

Thanks for providing a x-plat ZeroConf crate.

I had challenges getting the Example to work in a Linux container.

IIUC, the crate requires libavahi-compat-libdnssd-dev and dbus and avahi-daemon services.

When containerizing, I used:

ENTRYPOINT ["bash", "-c", "service dbus start && service avahi-daemon start && ./server"]

I think this (more commonly putting the commands in a script file) is the preferred way to start daemons needed for an executable

But I was unable to browse the service from the host as expected.

If I ran the commands manually (outside) of a subshell, it worked.

By adding a small delay between starting the daemons and running the server, the problem appears solved, i.e.:

ENTRYPOINT ["bash", "-c", "service dbus start && service avahi-daemon start && delay 2s && ./server"]

I'm reporting this here in the hopes that it helps someone else avoid -- what was for me -- an unexpected issue (and solution)

See: https://stackoverflow.com/questions/65043317/challenged-accessing-containerized-dns-sd/

You can easily mess up registration with too long, mistakenly placed . or _ on service types, these follow a standard so we could enforce that via a type string + udp/tcp enum.

ffi.rs has a lot of cruft from darwin/macOS that doesn't need to be there. We probably don't need to generate on the fly since this API is never changing but we should at least whitelist what we need.

This requires figuring out how to install the Bonjour SDK automatically, which I've only seen the runtime version available on things like Chocolatey.

Bonjour SDK is a login gated download from apple currently.

Would be nice and likely needed to have a way to check if ready, or even call functions that return WouldBlock instead of blocking. Allowing for better async programming and likely integration ability with Tokio/async-std