Entry Group and Legacy Service Names #4
-
Hello. Avahi provides the concept of Entry Group which combines the publishing of multiple services so they are acted upon at the same time. Does searchlight provide similar functionality? Also, I'm working on an AirPlay2 receiver app that requires publishing of two services:
Is there a way to fallback to legacy naming? I've tried every permutation of creating name labels I can find in searchlight but get errors due to the 'at' symbol. Many thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
I'm not sure what an Entry Group is, would you be asking for a discoverer that can listen for a group of services (e.g. via a Regex) instead of just a static name? As for broadcasting, one can add multiple services to a As for the |
Beta Was this translation helpful? Give feedback.
-
Appreciate the reply. Yes, I figured the answer to the 'at' sign question would be in trust-dns. What's interesting is trust-dns receives service names with an 'at' sign (enforce_ascii_std3=false) however prevents creation (enforce_ascii_std=true). As for entry groups -- reading the source it appears it's an Avahi design decision as a mechanism for grouping service definitions so they are registered/updated/unregistered atomically. The same result is possible simply by pushing two services. I suppose it's possible that some apps that query two services and depend on data from both could experience a race condition. For now I'm using https://github.com/keepsimple1/mdns-sd which doesn't restrict service names. |
Beta Was this translation helpful? Give feedback.
I'm not sure what an Entry Group is, would you be asking for a discoverer that can listen for a group of services (e.g. via a Regex) instead of just a static name? As for broadcasting, one can add multiple services to a
BroadcasterBuilder
As for the
@
symbol, the underlying DNS library (that parses mDNS packets and such) seems to not support that(?) It might be worth taking it up with https://github.com/bluejekyll/trust-dns as that seems to be a valid use case. I'm not sure if that's technically a legal DNS name though, so who knows. Main problem is that I would guess the library would fail to parse a packet with a@
in the received domain name as it isn't to spec.