Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!husc11!martillo From: martillo@husc11.HARVARD.EDU (Yakim Martillo) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: More questions about TLI Message-ID: <3415@husc6.harvard.edu> Date: Sun, 29-Nov-87 19:32:14 EST Article-I.D.: husc6.3415 Posted: Sun Nov 29 19:32:14 1987 Date-Received: Wed, 2-Dec-87 21:21:24 EST References: <8711181601.AA00849@janeb.wisc.edu> <305@halley.UUCP> Sender: news@husc6.harvard.edu Reply-To: martillo@husc11.UUCP (Yakim Martillo) Organization: Harvard Univ. Science Center Lines: 36 Ur-Unix had files which provided single data streams from single data sources. Pipes provided a simultaneous rendezvous between two processes over a full duplex stream. (Pipes in fact are a special kind of file.) These Ur-Unix concepts were inadequate for data communications and computer networking where a process might only be interested in one sub-stream of a multiplexed data stream coming from multiplexed sources. Further in a network environment simultaneous rendezvous between two process might not be possible. To replace simultaneous rendezvous, the Berkeley network designers introduced the client-server model which in fact replaces the process pair with one server and many clients which is particularly useful in decreasing load on network server machines. To deal with the problem of multiplexed data streams from multiplexed sources, and in order to realize the client-server model the Berkeley designer implemented the socket interface. Socket and bind provide a handle into multiplexed data streams. Accept, listen and connect help realize the client server model. Since files and pipes are just simple special cases of (singly) multiplexed data streams and rendezvous, the socket formalism provides a unified and effective formalism to files, streams, data communications and computer networking. Using sockets effectively reduces the "dimension" of interprocess communication problems and therefore should be the formalism of choice for implementing network software. [It is particularly nice that blocking and asynchronous I/O on terminals (a special case of a file), on files, on pipes and on sockets all behave identically.] I was unimpressed by the original streams designed by Ritchie who obviously understands the Unix model of computation. The Sys 5 designers who do not understand the Unix model of computation have apparently botched the implementation from what I amP+O_Z