On Fri 2002.11.01, Keith Moore wrote: > > 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. > and the app is also forced to live with delays and lower reliability > of DNS whether or not it is appropriate for that app. 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. I like to think that while this distinction isn't black and white, it is not altogether grey either. Again, this is precisely the kind of issue a working implementation is needed to answer, hence INFS. > 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. 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, 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. 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.) Please note that the thesis is not yet final, in that I need to rework it a bit and add some results, but it is sufficient to the extent of motivating and relating to INFS. Thanks for your thoughtful comments. I should add that our previous discussions re: addressless networking i-d last year substantially educated me and influenced the arguments in the sigcomm'02 submission and the thesis. sincerely, -prasad.