Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version nyu B notes v1.5 12/10/84; site csd2.UUCP Path: utzoo!linus!philabs!cmcl2!csd2!martillo From: martillo@csd2.UUCP (Joachim Martillo) Newsgroups: net.lan Subject: Re: socket library under System V? Message-ID: <3070002@csd2.UUCP> Date: Thu, 8-Aug-85 11:39:00 EDT Article-I.D.: csd2.3070002 Posted: Thu Aug 8 11:39:00 1985 Date-Received: Sun, 11-Aug-85 06:11:55 EDT References: <284@SCIRTP.UUCP> Organization: New York University Lines: 40 /* csd2:net.lan / dfh@SCIRTP.UUCP (David F. Hinnant) / 12:05 pm Aug 6, 1985 */ > We've been talking with various Ethernet vendors (Interlan, CMC, >Excelan, etc.) concerning implementing Ethernet on our 80286 Multibus >box under UNIX System V. Software-wise they'll give us a "socket >library", TCP/IP, a driver, and the BSD applications. All the pieces >are there; it's the "socket library" that has me a bit confused. 4.2 >BSD implements sockets in the kernel. I presume the socket library gives >the same functionality, but I don't see how. Can anyone that has this >kind of library tell me what it actually does? There is no need to implement sockets in the kernel though this is probably the better thing to do. Basically all the driver does is tell how to read and write the network interface and possibly send control information via ioctl commands. Presumably a user could write to the /dev associated with the ethernet interface directly via read and write system calls. The library will do this for you and tag on all the appropriate headers and what-not that are currently done in the 4.2BSD kernel. Now why is it better to do things as are done in 4.2 BSD? The Berkeley approach makes it far easier to approach ipc in a unified fashion even though you have many domains and many protocols and many communications devices attacked to your machine. In 4.2 you just invoke socket, bind, connect (or listen) for all of them. With a library approach you will have to rewrite your library and then probably relink your executables, should you also want to run some other protocol besides TCP/IP. If you want to do routing you can do this either in the application library or in the driver. Neither idea is good. There are also lots of minor benefits from putting all the grunge work in the kernel. Port allocation is simplified. Binary executables tend to be smaller (which can be important since ipc programs tend to proliferate when it all becomes available). Now why would you want to use the library/driver approach? Maybe you are stuck with system 5 or perhaps you are dealing with some hostile operating system supplier which won't let you see kernel source but will tell you how to write drivers.