Hi John, On 08/11/2011 17:19, John Fischer wrote: > Darren, > > Thanks for taking the time. Ethan and I spent a couple of hours > discussing these same points. See below. >
Thanks to looking into it more... > Thanks, > > John > > On 11/ 8/11 12:51 AM, Darren Kenny wrote: >> 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. > > Yes. We do present something on port 5555. The apache serving > manifests and related information to the clients. So we would have > 5555+N ports registered where N is equal to the number of configured > in network interfaces. Not ideal but read on.... > >> >> 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. > > No. That is not correct. The client does not use the port information > given in the DNSServiceResolve's callback. Instead it uses the embedded > port number within the text-record which looks like 'aiservice=<IP>:<port>'. > Sorry, that is what I meant, it doesn't use the port information in the mDNS record itself - i.e. the one being registered as 5555+N >> >> 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. > > Zero Conf should still work just fine. > >> >> 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? > > So what is actually happening is that the mdns daemon is producing > a warning because of the way that we are registering the service > (i.e., not a bug). We register the service on a per interface basis in a > multihomed configuration. In the case where all interfaces are being > used then we are fine. The only way to properly remove the mdns > daemon warning messages is to register the service once via > DNSServiceRegister() on one interface and then register additional > text-records on the other interfaces via DNSServiceRegisterRecord(). > The problem is that this method requires us to also modify the clients > to query for the records (DNSServiceQueryRecord()) instead of querying > for the service (DNSServiceBrowse()). Thus all of the S11 and pre-S11 > clients will break. Had I realized this fact well prior to S11 shipping > (read 6 months ago) I would have modified things appropriately then. > Part of the problem is that there is zero to no documentation on > this stuff and not a whole lot of expertise out there on it either. Hmm, not ideal, but it is what it is now. So... going forward, could we update the server and client to have support for the use of the DNSServiceRegisterRecord and DNSServiceQueryRecord. and if these fail then fail on the client, fall back to the existing method. The server would need to do both methods for now - if that's possible. This could then be pushed to an SRU and the customer eventually would have the correct configuration, and we could eventually obsolete the code that is really more of a work-around. > >> 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. >> * > > Yes. You can register on all interfaces (i.e., interfaceIndex=0). The > problem is that doing so violates the idea of multi-homed configurations > as the service will be available then on all interfaces including the ones > that we do not want. Though this does take care of the warning messages. OK, sorry, it wasn't clear to me that we weren't registering all interfaces in the existing code - if this 5555+N method is being used only where we are excluding some interfaces then that is fine. > >>>> - 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. > > Nope, not useful at all. Thanks, Darren. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
