Darren,
Thanks for taking the time. Ethan and I spent a couple of hours
discussing these same points. See below.
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>'.
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.
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.
- 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.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
