Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.att.com (Steven M. Bellovin)
Newsgroups: comp.unix.wizards
Subject: Re: buffer i/o using read(2) on BSD sockets
Message-ID: <12709@ulysses.att.com>
Date: 21 Mar 90 03:16:56 GMT
References: <129@cvbnetPrime.COM>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 24

In article <129@cvbnetPrime.COM>, aperez@cvbnet.UUCP (Arturo Perez x6739) writes:
> You may or may not recall that I claimed that the buffering on a BSD socket
> is visible to applications and sometimes even users.  For example, here's
> an excerpt from a Sun 3/60 man page for tar(1):


> B	Force tar to perform multiple reads (if necessary)
> 	so as to read exactly enough bytes to fill a block.  This
> 	option exists so that tar can work across the Ethernet,
> 	since pipes and sockets return partial blocks even
> 	when more data is coming.

> That's my best piece of evidence.  Now, you and I may know that it's not 
> strictly necessary to have this option, but there it is.

Without addressing your original claim, Berkeley had no choice on this
one.  The relevant factor is the TCP spec -- TCP has no concept of
records, and does not preserve record boundaries.  Thus, if BSD was
to implement TCP -- which was the purpose of the DARPA grant that
funded much of its development -- and if they were to support tar
across a TCP connection -- and tar format antendates 4.2bsd by several
years -- they had to do something at the application level.  Any
other possible implementation meeting those two constraints would
have similar properties.