Edward Pilatowicz wrote: > On Tue, Jan 30, 2007 at 03:49:26PM -0500, Rishi Srivatsavai wrote: > >> advertise information about the stream such as the audio codec. inetd >> controlled services using 'rpc' transport are not advertised via mDNS. >> DNS-SD Internet draft requires the transport protocol of the service to >> be either TCP or UDP. >> >> > > rpc is supported over tcp, udp, and tli transports. so it seems to me > that you could support mDNS for rpc over tcp and udp if you wanted to, > but you've chosen not to. (perhaps because you think that rpc doesn't > support tcp or udp? it's not clear from the above two sentences.) > could you elaborate on why you're not supporting rpc? > > The service instance name follows the naming conventions for SRV records. The second label in the service name must be "_tcp" or "_udp". But this is only a naming convention. Quoting section 7 of the DNS-SD Internet draft:
The "_tcp" or "_udp" should be regarded as little more than boilerplate text, and care should be taken not to attach too much importance to it. Since it is only a naming convention we can certainly advertise 'rpc' services as using say tcp as the transport protocol in the service name with no harm. So I agree this limitation is rather unnecessary and I shall look at including 'rpc' services as well. >> Future work: The master SMF restarter svc.startd(1M) could also be >> updated to support advertising network services using mDNS. There are >> currently no plans to add service discovery support in the master >> SMF restarter. Additional properties could be introduced for inetd >> controlled services to customize the advertised service name and to >> advertise additional information about the service. >> >> Open question: Considering the above future work to include this support >> in the master SMF restarter and new properties introduced to customize >> the service advertisement is it better to create the 'advertised' >> property under a new property group 'mdns' that is not specific to a >> restarter? >> >> > > to me, telnet doesn't seem all that interesting, i would be more > interested in things like ssh and httpd, and these services are > controlled by svc.startd, not inetd. so adding support for advertising > these services via an "inetd/advertised" property wouldn't make much > sense. it seems something like "mdns/advertised" would make more sense, > and it wouldn't be out of place since your making the restarters > mdns aware. > Advertising a vnc server managed by inetd would be interesting. With mdns support in inetd users can advertise inetd services they find most useful. I agree with the idea that if we are going to add mdns support in other restarters as well we should use a separate 'mdns' property group. > also, would it be possible to not make smf restarters mDNS aware, but > instead make the mDNS server SMF aware and have it access the > services repository to look for services that it should advertise? > and then somehow subscribe to relevant service state changes in the > repository? > > It might be possible. Could you please share any advantages with such a model or do you see any disadvantage with adding this support in the restarters? Thanks, Rishi
