[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: Thu, 18 Sep 2003 23:07:54 -0700

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?

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

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

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

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


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


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

Version: GnuPG v1.2.3 (Darwin)


reply via email to

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