Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Sockets vs streams.  An attempt to answer the original question
Message-ID: <1990Aug30.184748.6622@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <9008291448.AA14069@ftp.com>
Date: Thu, 30 Aug 90 18:47:48 GMT

In article <9008291448.AA14069@ftp.com> jbvb@ftp.com writes:
>    The way to do i/o on Dennis's streams was with "read" and "write".
>    Network i/o, in general, looked *exactly* like local device i/o.  This
>    is the way it should be...
>
>I would say rather that using read/write on network connections is
>the way most people would *like* it to be.  The reality is that on
>most systems the local filesystem is a pretty tame beast compared to
>a network connection.  Unless the OS/language combination's
>read/write was designed with network connections in mind (which means
>boolean flag arguments and wide variations in behaviour depending on
>them), use of read/write is likely to result in a cantankerous and
>unreliable network application...

Only if you have a cantankerous and unreliable network. :-)  True, the
network interface is more complex than most device interfaces (although
whether it is more complex than the tty interface, in particular, is a
debatable point!)... but most applications don't care.  They just want
to open a connection to service X on machine Y and reliably send bits
back and forth.  The complexities have to be present for the occasional 
sophisticated customer, but the simple customer shouldn't have to worry
about them.  The Unix tty interface is quite complex, but most programs
can ignore most of it -- if they want to print an error message, they
just say "fprintf(stderr, ..." and it works.  That's the way the network
interface should be too:  some simple way to open a connection (I find
it impossible to comprehend why 4BSD doesn't have an open-connection-to-
service-X-on-machine-Y library function, given how stereotyped and how
messy this job is), read/write for i/o, close for shutdown (and ioctl
for option setting etc. for those who care).  That's all most customers
want.

The networking facilities in Eighth/Ninth/Tenth Edition Unix within
Bell Labs are existence proofs that this approach can and does work.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry