User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
Thanks for the response, Marc.
Marc Krochmal wrote:
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.
however, you can get the TXT record via NSNetServices by first calling
"resolve" on the NSNetSerivce, and then by calling
protocolSpecificInformation.
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.
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?
Any further thoughts or suggestions? Should I file a 'feature request' on
the bugreporter?
--
Andrew White
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Rendezvous-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/rendezvous-dev/email@hidden
