Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ulysses.UUCP Path: utzoo!linus!gatech!ulysses!smb From: smb@ulysses.UUCP (Steven Bellovin) Newsgroups: net.lan Subject: Re: socket library under System V? Message-ID: <1056@ulysses.UUCP> Date: Tue, 20-Aug-85 13:10:16 EDT Article-I.D.: ulysses.1056 Posted: Tue Aug 20 13:10:16 1985 Date-Received: Wed, 21-Aug-85 07:13:36 EDT References: <284@SCIRTP.UUCP> <3070002@csd2.UUCP> <413@cheviot.uucp> Organization: AT&T Bell Laboratories, Murray Hill Lines: 63 > I always thought that a library implementation of sockets simply mapped > calls like socket, bind and send more or less directly into open, > ioctl and write. I don't see why you can't keep all the protocol dependent > code inside the kernel. Is it really that difficult to bend the socket > interface to fit the conventional device driver interface? If it is a > little awkward, then all the more reason to hide the grotty details in > a library, but why go to the trouble of introducing a new set of system > calls when the old ones are more or less adequate?? > > I'm not necessarily suggesting that the socket abstraction is a bad one, > but does it have to be in the kernel? We all use thelibrary > and that's not part of the kernel...! > > Please don't flame me about this - it's a serious question and I would > appreciate some discussion of the issues involved. It has been suggested that > the 8th Edition concept of a Stream can be used to implement sockets, > presumably through the ordinary open/read/write/ioctl special device > interface. Would anyone care to expand on this? There are a few things to make clear first; I've heard an awful lot of misconceptions about what sockets are, what streams are, etc. A socket is simply a new way to get a file descriptor from the kernel, as a handle for some sort of I/O operation. The conventional way -- opening a file -- has several disadvantages for network use, most notably that one name -- say, /dev/tcp -- must be multiplexed among many different users. There are assorted different ways of dealing with this, none of them particularly clean. Among the techniques I've seen are having multiple file names, such as /dev/tcp00 (used in UNET, 8th Edition UNIX); file names where the kernel plays games to treat network files differently, and hence multiplexable (3Bnet, BBN's 4.1bsd TCP/IP), having the kernel open a different file than the one you asked for (System V Datakit), and having some file names point to programs (v7 and 4.1bsd mpx files, some 8th Edition code). All of these mechanisms, with the possible exception of the 8th Edition funny file name code, have serious disadvantages (efficiency, modularity, cleanliness, etc.) Given that, adding a new system call is a clean and simple solution. Some of the additional new system calls -- getsockname(), for example -- are a bit dubious; there seems to be little reason why they shouldn't be ioctl calls. Others -- bind, accept, connect, and especially listen -- have sufficiently new semantics that they are perhaps justifiable. Things like send, sendto, and sendmsg strike me as unnecessary goo -- granted, they perform new functions (at least, in some of their aspects), but it isn't clear to me that the functionality is that important most of the time; you really end up with lots of feeping creaturism. Streams are a different ballgame entirely. To the user, a stream is a kernel-level filter that can be used with any stream file descriptor; this includes most character devices, pipes, and network devices and pseudo- devices. *It makes just as much sense to push a stream module -- say, a tty line discipline -- on top of a socket-derived file descriptor as on top of a real tty port that you opened* -- the two concepts are orthogonal. It wouldn't be at all difficult to add streams to 4.2bsd; it just isn't clear that it's worth my time. There is one other aspect of streams that is worth mentioning: streams are a kernel implementation technique that simplify new sorts of inter- connections. That is, they present a uniform technique for passing input to a wide variety of processing modules; if no demultiplexing is needed, output is handled that way as well. In effect, streams move the concept of the pipeline into the kernel. If the path between two modules is essentially dedicated (say, the one between tcp and ip), there is much less benefit to using these techniques; in structure, efficiency, and ease of use, they're roughly equivalent to mbuf chains.