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

[Stephen J. Turnbull]

>>>>> "Paul" == Paul Snively <address@hidden> writes:

    Paul> If you can look stuff up on that DNS server, you can
    Paul> discover those services. In that sense, the idea really is
    Paul> analogous to the LDAP registry idea, and apart from not
    Paul> requiring any additional infrastructure (assuming that you
    Paul> have a DNS server that supports dynamic updates) there's
    Paul> probably not much benefit to it.

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.

    Paul> OTOH, when you add mDNS to the picture,

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

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

That's false.  You still require the infrastructure.  However, it can
be self-configuring.  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?

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

    Paul> So there's some additional scaffolding that would have to be
    Paul> done at discovery time to go beyond the "I've found the
    Paul> FTP/HTTP/... service" to "I've found these arch archives."

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.

    Paul> As per my other e-mail, though, I'm striving to keep an
    Paul> infrastructureless solution available, and I took a moment
    Paul> to describe the relationship between DNS-SD and mDNS in
    Paul> support of that goal.

Why is "infrastructureless" good?  I thought the goal was to reduce
(explicit) configuration.  But lack of infrastructure reduces you to
"social" solutions.  ;-)

    Paul> How you keep "here" appropriately flexible given that DNS-SD
    Paul> only gets you to a host and port is another interesting
    Paul> question. Can we answer these questions, or are we better
    Paul> off looking elsewhere?

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.

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.

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

    Paul> Well put. I'm always surprised when people propose
    Paul> essentially social solutions and expect them not to have
    Paul> unacceptable failure rates. :-)

That's a mistaken association.  Some problems have only social
solutions.  (mDNS is essentially a social solution.)  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.

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

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.

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!

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

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

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