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