Hi,
We have a suite of applications that communicate with each other. A
very common thing :)
They usually learn about each other by reading settings in Registry,
config files and other unsightly places such as RDBM-es. The
aforementioned settings get entered by user through various
configuration tools and dialogs boxes during initial installation or
during maintenance. Getting the system set up correctly is a tedious
and non-obvious process. mDNS will allow us to equip the configuation
GUI-s with service discovery and achieve near perfect zero-config.
In all cases, we can come up with an URL syntax for defining locations
of service endpoints exposed by our applications. Say, web service
endpoints look like this:
http://hostname:port/handler?query-string
URLs are easy to store. Now how do we store DNS/SD service names? I do
not want to invent a special syntax for that. I want to store them in
the same place where traditional service endpoint URLs are stored. The
software should be able to distinguish traditional endpoint URLs and
DNS/SD service names. When it sees the traditional URL, it breaks it
up into usual things like hostname, port, query-string (where
applicable). Port can be a well-known number for the given URL scheme.
A or AAAA records can be discovered using standard DNS interface. Now
when it sees a DNS/SD service name, it needs to perform
DNSServiceResolve and also get A or AAAA records. Port number is
provided in the resolve reply. As you see both ways produce same
results: hostname, port, A, AAAA, query-string... The
URL-distingushing logic can reside in one library that is used by all
apps. This way only minimal changes need to be done to the rest of
business logic, and no special cases. Which brings me to
my suggestion:
DNS/SD service names can be formatted as special-purpose URLs. Here's
the proposed format:
dnssd://domain/service-type/service-name
service-name = UrlEncode(unicode-unescaped-service-name); // (*)
service-type = /* does not need any encoding ! */
domain = DnsCompliantEncode(unicode-unescaped-domain);
What DnsCompliantEncode does is a bit fuzzy. I guess at this point it
should follow Rendezvous domain name escaping rules. Someone pointed
out that commonly deployed DNS servers do not understand these rules.
One hopes eventually an encoding scheme will be employed that satisfies
all parties.
One more point about this encoding scheme: it does not attempt to
introduce an internal service name (which DNS/SD draft actively argues
against). It merely introduces an algorithmic transform between
user-visible service name and a serialized version storeable where
URLs are typically stored.
Examples:
dnssd://apple.com/_http._tcp/Some%20Imaginary%20Web%20Service
"Imaginary Web Service" _http._tcp "apple.com"
dnssd://local/ _daap._tcp/Pavels%20Music
"Pavels Music" _daap._tcp "local"
dnssd://local/_dictionary._tcp/Fran%c3%a7ois
"François" _dictionary._tcp "local"
Has anyone dealt with a similar situation? Is there a better way?
--
Notes:
* W3C suggested implementation of Unicode-aware URL encoding:
<http://www.w3.org/International/O-URL-code.html>
--
Pavel Repin
_______________________________________________
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
This email sent to email@hidden
