On 07/11/2011 18:26, John Fischer wrote: > Darren, > > Thanks for the review. Your questions are very valid and some > that I asked myself while trying to come up with the solution. > See below. > > Thanks, > > John > > On 11/ 7/11 02:45 AM, Darren Kenny wrote: >> Hi John, >> >> The code looks fine, but I have a question about the approach: >> >> - Is it possible that the incremented port-count could conflict >> with an existing service? > Yes. However, that is also true with our original port number 5555. > The good news is that this is just the advertised port number and > nothing is actually bound to it just yet on the system. I know confusing. > I thought that when we registered the service the mdns daemon that > the port number would be allocated and reserved. It is not. It seems > that it is simply part of the stored data within the mdns daemon. >
But we do actually present something on port 5555 usually. So from what I understand, the client doesn't use the port information at all - is that correct? As such the port isn't important for our own use. But this also means we're advertising something via mDNS which is simply not there - so anyone attempting to use the 'Zero Conf' mechanisms outside of AI will be confused by this - it seems just plain wrong to do this. Is there any bug logged against mDNS to get them to fix the issue in there which doesn't allow the advertisement of the same port on multiple interfaces? Is it not possible to, when registering the service the first time, to ask it to be made available on all interfaces? mDNS does seem broken if it doesn't allow either option to work. Looking at the dns_sd.h header it would appear that this should be possible according to the comments: /* DNSServiceRegister() Parameters: ... * interfaceIndex: If non-zero, specifies the interface on which to * register the service (the index for a given interface * is determined via the if_nametoindex() family of * calls.) Most applications will pass 0 to register on * all available interfaces. See "Constants for specifying * an interface index" for more details. * >> - Would it be better to not just increment the port, but to check >> specifically for the error in question, and only then do the >> increment - possibly repeating until it finds a free slot. > > That would be awesome but the only errors that would correlate > for our specific case are: > > kDNSServiceErr_AlreadyRegistered > kDNSServiceErr_NameConflict > > However, when the servicename and ports are the same neither > are passed to the register_callback function. In fact the error > code is always kDNSServiceErr_NoError. That's useful, not. > >> - Or possibly a mix of this testing for the error and the >> existing solution - with the testing of the error to avoid >> conflict that could arise while picking ports? > > Again, if we could determine that an error occurred then > we could take appropriate action like bumping the port > number until we find something that is available. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
