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

[Paul Snively]

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

Hi Stephen!

On Wednesday, September 17, 2003, at 09:49  PM, Stephen J. Turnbull 
wrote:

> I don't understand this comment.  A DNS service (note: NOT "server")
> is necessary in the modern environment, and you have to know where to
> get it.  So piggybacking on that reduces client complexity.  Since all
> these things are directory services, it probably add little to server
> complexity, and so reduces system complexity ("infrastructure") a lot.
I just meant that if you had to ensure that either a DNS server or LDAP 
server were available on the network _for service discovery reasons_, 
there wasn't an obvious reason to prefer one over the other.

> mDNS is scary.  I spent almost a year having my LAN service degraded
> by storms from MS Windows systems "browsing" for shares and stuff like
> that.  Multicast helps, but ....  Have you read "Why Gnutella Can't
> Scale, No Really", and its references?
>
> http://www.darkridge.com/~jpr5/doc/gnutella.html
I'd read it before, but not for some time, so took the opportunity to 
read it again. While it's certainly a stirring indictment of the 
Gnutella protocol, it's far from clear what this has to do with mDNS. 
Ditto Windows shares. On the other hand, I haven't seen reports from 
admins where mDNS is used heavily yet, either. I'll try to find 
some--most likely at Apple.

> That's false.  You still require the infrastructure.  However, it can
> be self-configuring.

A fair point--the terminology is from the ZeroConf RFCs, but I agree 
that it could be crisper.

>   But that's valuable according to situation.  In
> the office environment, with traditional methods, you configure the
> system once, then forget it---no big deal.  Does that mean there's no
> infrastructure?
In the sense that I think the RFCs use the term, yes, which reinforces 
your point that the terminology is flawed.

> Furthermore, mDNS actually requires _more_ infrastructure in the sense
> that the DNS is now non-hierarchically distributed, at least if each
> host is going to be responding about its own services.  Not to mention
> the burden it likely places on the physical network.  (I don't have a
> problem with this; eg, if you have an active RDBMS you can look at, go
> take a look at the relative sizes of the "data" and the indicies.  I
> don't expect mDNS bandwidth usage in those proportions, but definitely
> it's not a waste to transmit lots more metadata than we currently do.
> It _is_ a cost that we need to budget for, that's all.)
Quite right. It would be interesting to have some information as to, 
e.g. how easy or hard it is to deploy mDNS on Windows or Linux, and 
then to get some real traffic numbers from it.

> You definitely want an "arch" service.  However, the assigned port
> doesn't take you directly to arch; it takes you to the arch archive
> directory service.
I've done a little more reading on DNS-SD, and this doesn't appear to 
be necessary: we can indeed specify that an "arch" service lives at a 
particular URL. See page 11 and beyond of 
<http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>.

> Why is "infrastructureless" good?  I thought the goal was to reduce
> (explicit) configuration.  But lack of infrastructure reduces you to
> "social" solutions.  ;-)
Yes, given your correction of the terminology, I agree.

> I think that having something like "tla archives --browse-ns" which
> calls the DNS to find arch-archive-directory services in "nearby"
> domains, then queries them for URLs to public arch archives offered is
> feasible with the technology so far described.
See above: we can actually have straight DNS-SD support for URLs. Once 
again, this observation is totally distinct from the mDNS issue.

> The arch-archive-directory server can be pretty trivial.  It could be
> implemented as a trivial TCP server that simply returns a text file of
> archive name--archive location pairs, or a mail (SMTP port) to
> arch-archive-directory, which triggers an autoresponder, or an LDAP
> server, or an HTTP URL, whatever seems likely to be the most common
> infrastructure, and lightweight to install if not present.
It turns out to be so trivial as not to be necessary. :-)

> "tla publish-archive" would add the name--location pair to
> /etc/arch/=exports/ (or equivalent), which would be a directory like
> ~/.arch-params/=locations/, not a file.  This way it could have
> permissions so that files there are world-readable but writable and
> mv/rm-able only by owner.
And now we're back to where we left off on the other thread, with the 
thought that an extended "tla grab" might somehow be the tool that's 
related to the registration process, although maybe that's meant at the 
receiving end rather than the publishing end; it's not yet clear to me.

> That's a mistaken association.  Some problems have only social
> solutions.  (mDNS is essentially a social solution.)

I'm not sure what you mean by this. mDNS is a technology.

>   Social solutions
> are often effective and very efficient when the "social radius" of the
> problem is less than the "social radius" of the solution, and the
> "center" of the problem moves with the "center" of the solution.
Yes, as in flocking behavior. I'm not sure I understand how the analogy 
applies here.

> The problem here is the mismatch of the social radius of vcards (those
> people you happen to exchange them with who implement the protocol and
> are willing to put in the effort to update the nonstandard field) and
> that of the problem (all public arch archives worldwide that might go
> to the same conference you're going to).
Ah, a good example, thanks.

> NB: if the archive in question is at home, and the conference net has
> global internet access, this will work quite well, actually.  So this
> would work well for a CVS-based developer.
Exactly. Thank you. All of this talk of "well-known this" and 
"well-known that" completely overlooks one of arch's distinguishing 
characteristics that I'm trying to leverage.

> But what if (as will be common with arch users) the archive is on the
> notebook in your new acquaintance's briefcase?  Then the vcard has
> travelled out of its solution radius.  That is, odds are that the
> vcard points "back home", which is the wrong place.
>
> So the vcard scenario looks like
>
> 1.  you wake your notebooks
> 2.  you get his vcard
> 3.  you "tla abrowse" and get his public archive on the company server
> 4.  he goes, "oops, latest version is on this notebook"
> 5.  he tells you his conference address and the archive name
> 6.  you mistype it [optional, if omitted goto step 8]
> 7.  tla abrowse says "no such archive"
> 8.  you register the name/location pair correctly
> 9.  tla abrowse tells you what you want to know and you do a get or
>     archive-mirror
>
> Note carefully the glaring bug in step 5: his vcard was not updated.
> Some people will get that right.  But I'll bet dollars against donuts
> that _you didn't update your vcard and won't do so until step 5 when
> you play the "have archive, will travel" role yourself_.  Note also
> that when you get home, your copy of his vcard has the now invalid
> conference location on it!
This is an incredibly helpful problem statement. Coupled with your 
clarification of the "infrastructureless" terminological flaw, I think 
you've succeed where I've failed to be crisp and clear.

> What Paul's solution does that the vcard solution doesn't is that the
> two of you sit down, wake your notebooks, DHCP and mDNS do their
> things while you're drinking coffee, and then you just "tla abrowse
> address@hidden" followed by "tla get" or "tla
> archive-mirror".
Bingo.

> Oh, and by the way, the vcard users' coffees are cold ;-).
LOL!

This has been the most valuable exchange so far--vastly superior to 
anything I could have written. So let me just emphasize once more that 
DNS-SD is distinct from mDNS so interested parties can perhaps discuss 
the pros and cons of arch and DNS-SD (and/or other service discovery 
systems, of course) without concern about mDNS effects, and we can take 
the unrelated mDNS discussion off-list.

> --
> 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.

Many thanks and best regards,
Paul

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

iEYEARECAAYFAj9qnUIACgkQugPBK9Detep7bQCgwJm1tls9WVzr72hnbwk6+vHI
bYkAn1eF2QcLtZfICsH1Yn+a9Plmp2R2
=K0nU
-----END PGP SIGNATURE-----