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