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