[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Snively
Subject: Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata
Date: Wed, 17 Sep 2003 07:41:10 -0700

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 network via DHCP.
(2) Do a SRV query for LDAP in the 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 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,

Version: GnuPG v1.2.3 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]