Please check out http://infs.sourceforge.net for a novel INternet
FileSystem (INFS) package which appears to be ideally suited to
cell phones and other small devices or appliances. By pushing the
DNS resolution to the kernel, INFS means to achieve the following:
- eliminates sockaddr_t handling in the user space, allowing
application code to become free of IPv4/IPv6 (or for that matter
raw Ethernet or ATM) dependencies;
so when the address changes out from under the app, or there are
multiple hosts bound to a single domain name, the app loses.
I don't see why name-address caching within the kernel cannot be as
good or as bad as caching in the user space. I believe this would be
an important area that the current Linux implementation of INFS allows.
The issue I'm concerned about is not where DNS cacheing is done, nor
is it whether there is an interface that allows apps to open sockets
based on DNS names. The issue is whether the app has the ability
(without too much hair) to specify socket endpoints using IP addresses
rather than DNS names. Another issue is whether the app has the
ability to perform DNS queries directly.
Basically and for a variety of reasons DNS is not suitable for all
purposes, or for all apps. My concern is that an API that "encouraged"
apps to use DNS (by making it difficult or infeasible to use IP addresses)
would cripple that's platform ability to support some kinds of apps.
Programs which more directly concern the IP infrastructure, e.g. like
traceroute or tcpdump, should naturally continue using IP addresses
as arguments. It is only for "true apps", for which use of DNS names
as command arguments is as such recommended, that INFS use is envisaged.
There are more apps that need to avoid using DNS than those "which more
directly concern the IP infrastructure". For instance, any app for
which connection setup time is an issue, or for which performance can
be improved by careful selection from a variety of servers, is a
candidate for not using DNS - at least not on every connection setup.
sockaddr support. why are you trying to wean apps off of using
IP space when for many purposes DNS is even worse? DNS is slower
and less reliable than IP, no more consistent than IP, and DNS names
are as overloaded as IP addresses.
The previous paragraph answers this to the extent INFS supplements
the current status quo and the limitations of the DNS.
I don't see how INFS supplements the limitations of DNS at all. The
best it can do is shrink the application footprint (which usually
isn't an issue as the DNS library is shared anyway) and slightly reduce
the amount of code in the app. It certainly doesn't improve DNS
reliability or performance.
There is a sounder philosophical/physics argument, given in my thesis
(section 1.3/1.4), for the idea of weaning apps off IP or similar
numeric address spaces. Very briefly, the two main reasons are (a)
that any fixed-length numeric address space automatically sets a
hard limit and resists expansion, as we are finding from the IPv6
migration,
Personally, I would prefer a variable length address space, and I think
the technical performance issues with this could have been addressed.
Having said that, it's not at all clear that 128 bits is a "hard limit"
in the sense that 32 bits was. This really depends on whether having so
many address bits causes addresses to be used for many more things than
they were previously used - i.e. far more than one address per host.
Even assuming that a variable-length IP address were better, that would
not argue for trying to overload DNS names to do that job.
and (b) not depending on fixed-length numeric addresses
as primary (user & application level) addresses would enable the
network to auto-aggregate its addresses and routes.
So you'd prefer that the network advertise routes to DNS suffixes
to having it advertise routes to IP prefixes, and forcing DNS
to reflect network topology?
A more consistent
and less overloaded namespace is naturally required, and is at least
partly addressed by the alternative namespace (ANS) described in the
thesis. (The driver for ANS would be simply another INFS kernel module
like the dns driver in INFS.)
Forgive me if I don't read your whole thesis right now. If you have
a 10 or 20 page summary I'd be willing to look at that.
Keith