Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Wednesday, September 17, 2003, at 06:26  AM, Stephen J. Turnbull 
wrote:

> Right.  But wouldn't it be more pleasant (not to mention less
> typo-prone) to pull your "short-list" from a menu (which could even
> suppress the URLs), than to type them in?
This is a big part of what I'm driving at: arch (rightly, IMHO) 
enforces a nice, regular naming convention, at the cost of being 
somewhat unforgiving of mistakes and somewhat verbose. The less 
remember-and-type here, the better.

> This is equivalent to what Paul is talking about, except that the
> feature that Paul is talking about requires only one well-known "URL"
> for discovery of all services, and is optimized for that purpose.
It's really leveraging a well-known service that we all expect to be 
there anyway: DNS. (So far in this discussion, I've really been 
conflating two distinct things, DNS-SD, which doesn't require multicast 
but rather only dynamic DNS updating, and mDNS, which is an 
implementation of DNS that uses multicast. I'll try to be more precise 
from now on.) All DNS-SD really is is a mechanism for registering 
services and their locations in a DNS server using plain ol' DNS 
records. If you can look stuff up on that DNS server, you can discover 
those services. In that sense, the idea really is analogous to the LDAP 
registry idea, and apart from not requiring any additional 
infrastructure (assuming that you have a DNS server that supports 
dynamic updates) there's probably not much benefit to it.

OTOH, when you add mDNS to the picture, it changes significantly: this 
gives you infrastructureless support for enough of DNS to do DNS-SD, at 
least, on the local link. Anyone with an mDNS responder on their system 
now has the ability to lookup registered services on their own machine. 
This is the part that won't scale to the Internet (what with the 
multicast). But that's a separate issue from whether it's a good idea 
to use DNS-SD or not.

So the upshot is: if you use LDAP etc. you need relatively fixed 
infrastructure. If you use DNS-SD you can take advantage of relatively 
fixed infrastructure, i.e. a DNS server. But you leave open the 
possibility of using mDNS in support of DNS-SD and requiring no 
infrastructure.

Does that make more sense?

> The two big questions I have about Paul's idea is that (1) the RFC
> 2782 SRV record will not give you a file system path, only a
> port---effectively, the service is assumed to be unique on that host,
Yeah, this is the unfortunate piece that's come up already.

> and (2) not only does arch support multiple transports (this bullet
> could easily be dodged simply by defining arch-ftp, arch-http, etc
> services), but also it many hosts will want to publish multiple
> archives.  This means that problem (1) is inherent.
Yes; it means that the port is a chokepoint of a kind: there can be 0-N 
arch repositories behind it. So there's some additional scaffolding 
that would have to be done at discovery time to go beyond the "I've 
found the FTP/HTTP/... service" to "I've found these arch archives." I 
haven't yet put any thought into what this would look like.

> The obvious way to dodge this is to provide a network service named
> "arch-archive-directory" with an arbitrary port, connect to it, and
> get a list of arch archives available.  However, something more
> general, maybe LDAP, would probably be a better idea.  So the protocol
> would be something like
>
> (1) Join the big-conference.acm.org network via DHCP.
> (2) Do a SRV query for LDAP in the big-conference.acm.org domain.
> (3) If it exists, contact the server and register your archives with
>     it (I'm a bit fuzzy on whether this makes sense with LDAP, maybe
>     you'd need a more on-line directory service with some kind of
>     authentication and real-time database updating, but LDAP allows
>     recursive querying of other servers IIRC, so what you'd do is have
>     your local LDAP registered with the conference's, and it would do
>     the querying to build up its cache).
This isn't a bad idea, especially for platforms with LDAP already on 
them. I'm sure something essentially analogous could be done without 
LDAP. As per my other e-mail, though, I'm striving to keep an 
infrastructureless solution available, and I took a moment to describe 
the relationship between DNS-SD and mDNS in support of that goal.

> Right ... and Paul is recommending DNS-SD in particular.  He's not
> saying that arch needs to _do_ anything; it just needs to be
> "registered" (whatever that means in this context) and ready to answer
> the door when you knock.  And it could provide a convenience wrapper
> over a more general service directory service.
That's exactly right: the challenge (in my mind) is to let the world 
know that there are public arch archives available "here." What "here" 
means given that arch is transport agnostic is an interesting question. 
How you keep "here" appropriately flexible given that DNS-SD only gets 
you to a host and port is another interesting question. Can we answer 
these questions, or are we better off looking elsewhere?

> Of course.  The point is that creativity doesn't scale, a standard (if
> carefully designed) might.
Well put. I'm always surprised when people propose essentially social 
solutions and expect them not to have unacceptable failure rates. :-)

> --
> Institute of Policy and Planning Sciences     
> http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba                    Tennodai 1-1-1 Tsukuba 
> 305-8573 JAPAN
>                Ask not how you can "do" free software business;
>               ask what your business can "do for" free software.
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iEYEARECAAYFAj9oco4ACgkQugPBK9Deteo0jACfZH68ug/I2r5ykWJJwkBKjd7P
4pQAoN8dRCAFQOF7GJX7XmUo5YfCQ1Vh
=b6SZ
-----END PGP SIGNATURE-----