Hi Andrew,
> Sorry for the bump, but does anyone know how to obtain the TXT
record
> given a NSNetService? At the lowest level, I can call
> DNSServiceQueryRecord with the domain name received / constructed
from
> the NSNetService result and rrtype TXT, but this feels clunky and
> bypasses the Cocoa framework, not to mention requiring me to build
a
> completely separate callback processing loop.
Actually, using DNSServiceQueryRecord isn't really that difficulty,
Difficult, no. But definitely clunky, in that I need to set up a
customised select loop in parallel with the main event loop in order
to handle DNSServiceQueryRecordReply responses. I'd either need a
thread (don't want to go there yet) or a non-blocking select call
patched into the main event loop.
If you wrap the socket in a RunLoopSource, you can add it to your
standard event loop. There's an example of this in the following
sample code...
however, you can get the TXT record via NSNetServices by first calling
"resolve" on the NSNetSerivce, and then by calling
protocolSpecificInformation.
Here's a Q&A that talks about TXT record formats.
<http://developer.apple.com/qa/qa2001/qa1306.html>
Hope that helps.
Unfortunately, this Q&A seems to conflict both with the reply I
received from Chris and my own experience...
Data point 1:
Chris Parker wrote:
-protocolSpecificInformation was unfortunately pretty much deprecated
at publication, so you may have to use the raw DNS-SD APIs if that's
vital to you for arbitrary items, but for information published in a
like manner (i.e. the other side called
-setProtocolSpecificInformation
on the NSNetService instance it's publishing) it should work.
Data point 2:
Calling protocolSpecificInformation on my records (which I know
contain correctly formatted TXT data) returns empty strings, as far as
I can tell.
This is consistent with Chris' statement that
protocolSpecificInformation returns only data set using
setProtocolSpecificInformation, and not arbitrary but correctly
formatted TXT records.
Rendezvous Browser uses NSNetServices to display the TXT record data,
so I can only assume that protocolSpecificInformation is working.
I'm pretty sure that iPhoto uses it as well. If you want to send me
your code, I can take a look.
Unless the TXT record is only parsed if it uses '\001' as a separator
rather than length bytes? However,
In Mac OS X 10.2.x, the Rendezvous APIs use an ASCII 1 ("\001") as the
> boundary marker between constituent strings within the DNS TXT
record,
> and then the TXT record is automatically converted to the correct
format.
I've not experimented with the opposite configuration: publishing a
TXT using setProtocolSpecificInformation and sniffing using something
that is format-aware.
Even if it did work, I still have the a possible issue that
protocolSpecificInformation doesn't seem to have any way of handling
binary data. If a raw '\000' or '\001' turns up in the data field -
or indeed any other unprintable character - what happens?
That's true. protocolSpecificInformation cannot handle binary data,
which is why it's been deprecated in Tiger and replaced with a new
method that returns the raw TXT record in <length><data> format. So if
you need to support binary TXT record data, you'll need to use the
DNSServiceDiscovery API.
