On Tue 2002.11.05, John Stracke wrote:
> >I see both as largely system calls API issues, permitting simple and > >elegant solutions, and as not fundamental networking constraints that > >would legitimately rule against the INFS approach. > > > I disagree. The answers you give seem to say that you assume there are > only a few possible variations on an application's needs, which is not > the case. Au contraire, I am simply being more open to the idea that the OS interface can be as simple and general as applications need it to be. But, that's admittedly a matter of faith - in some cases, for example, with SysV's streams modules, the generalization can become complex enough to limit it from general adoption. > (a) This requires that the kernel be able to support the cache logic > that the app needs. The only way to support apps with novel > requirements is a minimalist API on which the app can build its own > logic. That's the lesson of Unix--and, for that matter, of IP. True, so aren't you assuming that use of INFS somehow prevents use of the traditional socket system call for the special needs? The lesson of Unix is also that while we provide a high level i/f that suffices for most apps, we also provide a low level i/f - viz the /dev/hd0, /dev/hda etc. interface available for special needs. It's in Windows that I don't see a convenient low level access for the disk, the usb, etc. Unix is a minimalist, not a restrictionist, philosophy, and this is in fact reflected in my implementation - the kernel patch merely adds sock_morph() and sock_demorph() to support INFS, it doesn't subtract anything. All I'm saying here's another way, try this too, maybe in some cases, like small wireless devices, you'll find it advantageous. It doesn't have to be equally advantageous for large, wired servers. > (b) Per-process is not sufficient, because a given process may need > several different styles of caching. For example, consider a > conferencing program with an embedded LDAP client. I meant that as example. The source code is there so that people can try more imaginative things out if they want to. (so please don't give me *all* the ideas or the others will feel left out ;-) > >For the second requirement, a simple known approach is to pass the already > >open (socket) file descriptor as argument when opening the secondary > >connections, so that the fd serves as an abstract handle for the previously > >obtained address. > > > That works only if the first connection is still open. True, but that's not the only trick up the kernel programmer's sleeve. > In addition, not all applications use connected sockets. If you're > using a UDP-based protocol, it may be more efficient to have a single > unconnected socket, and specify the recipient address on each packet you > send. This is especially true for servers; if you've got lots of > requests coming in, and they don't require a lot of user-space CPU, then > the cost of creating a new socket for each request could add > significantly to the cost of serving the requests. Of course. The neat trick of INFS is that it reuses the open(2) system call for connected sockets, since the filename argument can be used for the DNS pathname. However, it's a trivial matter to arrange the code to return an unconnected socket for a null filename argument, which is what you'd generally want for server-side sockets. With unconnected sockets, it is known that you can't use read()/write() calls in any case, and must use the send()/recv() calls that take a destination parameter. For the INFS version of send/recv, we'd allow a DNS name as the destination argument, but note, as already mentioned above, that the low level socket API remains intact - the old send/recv calls will work. > And you think you won't encounter inertia trying to get people not to > use sockaddrs at all? No more than Linus' world conquest, which gives me hope, imho! > Securely? And what about all the non-TCP-based protocols? Perhaps - why not check out the Snoeren-Balakrishnan paper? I'll assume that, for the purposes of my thesis, those problems are or will be solved by people specialized in those areas. Also, I'm tempted to add: And what about all the non IP-based protocols, for good measure? Are we absolutely sure that there is no good feature in any of them that we have not already compromised by going to IP? [I do allow for non IP protocols also in my thesis, since with names as primary addresses, I can have that luxury. It is IP, IMHO, that appears to be more biased and restrictive.] -p.
