[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: |
Fri, 19 Sep 2003 18:39:04 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Stephen!
On Friday, September 19, 2003, at 12:40 AM, Stephen J. Turnbull wrote:
Just that protocols that browse for distributed resources can be hell
on a network. One has to be very careful.
Agreed that the designers of such protocols need to be careful.
Hehe. (1) This isn't an RFC, even, yet.
Time will resolve that issue, such as it is.
(2) My guess is that the DNS
TXT record is just plain dead in the water. Why? Because many DNS
implementations are restricted to 512 (yep, you can count 'em on your
fingers if you're a centipede) _bytes_ of returned data. So what
you're suggesting surely requires multiple trips to the well.
This is addressed in section 6.2 of
<http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Certainly
most URLs fit nicely in 512 bytes or less.
(3)
That's on a datagram service.
It's unclear to me what the significance of this is.
(4) And it's deprecated by the authors
anyway. The lpd example is about _backward compatibility_. New
protocols SHOULD NOT depend on it.
This is far too strong. It's true that they use the word "legacy" to
talk about services that don't do feature negotiation on their host and
port, but earlier, in section 6. we find:
"Similarly, a file server may have multiple volumes, each identified by
its own volume name. A Web server typically has multiple pages, each
identified by its own URL. In these cases, the necessary additional
data is stored in a TXT record with the same name as the SRV record."
These examples demonstrate that use of DNS-SD for precisely the type of
service that a public arch archive represents has been contemplated and
is supported by the DNS-SD authors. The use of the TXT record in such
cases is not at all deprecated; section 6. and its subsections are
precisely about defining how the TXT record can be used to provide
necessary additional information, such as a URL, to make effective use
of a service.
This is _definitely_ going to be hell on the conference network at
registration hour. Not to mention abuse of the whole DNS idea. The
DNS was never intended to be a directory for arbitrary text.
And no one's asking for it to be; it's being asked to be a directory
for arbitrary services. And it's going to be no more hell on the
network at registration hour than a bunch of people hitting the same
HTTP server or Wiki server at the same time would be (keep in mind that
we're talking about DNS-SD, not mDNS; that's a separate discussion).
My guess is that the IETF will say: if you want to use SRV records to
discover lpd queues, rewrite the lpd protocol spec.
No one's talking about lpd except as an example of how DNS-SD can even
support services that weren't designed with it in mind.
tla grab is technologically trivial, and it's a social solution.
Yeah, and so far in my investigation it doesn't seem relevant at all.
mDNS amounts to walking into a crowded room and yelling, "Yo, is Paul
Snively here?"
No; it amounts to having my machine say "Yo, public arch archive here!"
every five minutes.
That's social behavior; you're talking to a specific
group, the ones in front of you, and who knows if anyone will bother
to answer?
They don't have to answer. The information will get to them with a high
degree of probability of success. Certainly higher than with word of
mouth.
And sure, humans are more fallible than machines, but UDP
is pretty fallible as mechanical technologies go. Especially in the
packet storm that is likely to characterize registration hour at a
conference.
I think you may wish to read the mDNS docs and follow the IETF ZeroConf
working group discussions at
<http://www.merit.edu/mail.archives/zeroconf>. I think you'll be
pleasantly surprised to find that these issues are receiving the
attention that they deserve. But once again, at the moment, I'm more
interested in concentrating on service discovery (DNS-SD or otherwise)
apart from mDNS considerations.
DNS-SD as written in that draft looks to me to suffer from severe lack
of the kinds of experience that informs the Gulbrandsen, Vixie, Esibov
RFC for SRV records.
From <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>:
"We would like to thank (in alphabetical order) Richard Brown, Josh
Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their
contributions."
From
<http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>:
"The concepts described in this document have been explored and
developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, and
others."
I think it's years from acceptance, and two of
the features that arch might want to depend on (DNS TXT records and
multilevel protocol discovery, cf the _anon._ftp._tcp example) are
likely to be extremely controversial.
It seems that TXT records of 512 bytes or less are comparatively safe.
I don't see the connection between arch and multilevel protocol
discovery. Nevertheless, it's also not clear to me why multilevel
protocol discovery should be controversial.
IMO YMMV IANAL etc. but I think
we're better off looking for a solution we can implement today in
conformance with the existing RFCs.
Too late, in a few important senses: there aren't any competing service
discovery systems that have any wider acceptance; ZeroConf is in the
IETF working group phase and is being standardized; and it's already
shipping on the 2nd most popular consumer platform in the world. If
someone can challenge me on the first point, I'd be thrilled--I'm
always interested in good technology
(<http://www.cs.cornell.edu/Info/Projects/Ensemble> and
<http://www.spread.org>, for example). There are no factual challenges
to the latter two points.
A major aspect of my point is precisely that this _can_ be implemented
today, and in fact the ZeroConf RFC drafts _are_ in conformance with
the existing RFCs ("This document describes a convention for naming and
structuring DNS resource records. Given a type of service that a client
is looking for, and a domain in which the client is looking for that
service, this convention allows clients to discover a list of named
instances of that desired service, using only standard DNS queries" and
"This document proposes no change to the structure of DNS messages, and
no new operation codes, response codes, or resource record types. This
document simply discusses what needs to happen if DNS clients start
sending DNS queries to a multicast address, and how a collection of
hosts can cooperate to collectively answer those queries in a useful
manner.")
From your previous message, it's clear that you understand the value
proposition. Unfortunately, from this response, it's far from clear
that you understand who is behind DNS-SD and mDNS, the level of design
effort that's been put into it, or its adoption rate. Still, fine: if
you have an alternative suggestion that addresses the process that you
described so well, I absolutely want to know about it. In the meantime,
I'll continue working with David on the spaces-in-filenames and
AppleSingle support and revisit service discovery after that.
--
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)
iEYEARECAAYFAj9rr8AACgkQugPBK9DetersbgCfR/5gN/XoIIg96yANkcTBn0W0
6T4AoIJOJz4Qy08WhTj8H2QKSHxHWi5V
=ROoO
-----END PGP SIGNATURE-----
- [Gnu-arch-users] Re: Ruminations on Arch Desiderata, (continued)
- [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Doran Moppert, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Tom Lord, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata,
Paul Snively <=
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Robert Collins, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Stephen J. Turnbull, 2003/09/20
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Andrew Suffield, 2003/09/17
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Doran Moppert, 2003/09/18
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/19
- Re: [Gnu-arch-users] Re: Ruminations on Arch Desiderata, Paul Snively, 2003/09/17