Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.archives
Subject: [comp.unix.wizards] Re: buffer i/o using read(2) on BSD sockets
Message-ID: <11271@stag.math.lsa.umich.edu>
Date: 6 Mar 90 01:44:54 GMT
Sender: news@math.lsa.umich.edu
Reply-To: libes@cme.nist.gov (Don Libes)
Followup-To: comp.unix.wizards
Lines: 37
Approved: emv@math.lsa.umich.edu (Edward Vielmetti)
X-Original-Newsgroups: comp.unix.wizards

Archive-name: sized_io/05-Mar-90
Original-posting-by: libes@cme.nist.gov (Don Libes)
Original-subject: Re: buffer i/o using read(2) on BSD sockets
Archive-site: durer.cme.nist.gov [129.6.32.4]
Archive-directory: pub
Archive-files: sized_io.shar.Z
Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)

In article <637@lot.ACA.MCC.COM> ables@lot.ACA.MCC.COM (King Ables) writes:
>I want to read an arbitrarily large block of data and not have to worry
>about message boundaries (hence read/write rather than send/recv).
>
>This works fine on a socket connected between two processes on my Sun up
>to a buffer size of 4096.  Anything after that doesn't seem to make it.
>I get (for example) 8000 back from write(hd, buf, n) where n=8000, but
>when I read(hd, buf, 8000) I get 4096 and a successive read(2) returns -1.

Well, what's the value of errno?  Note that expecting to be able to
read arbitrarily-large packets is unrealistic due to limited kernel
buffering and protocol design.

I know you don't want to encapsulate your I/O, but that is the only
solution.  I have some code that does it which you can anonymously ftp
from durer.cme.nist.gov as pub/sized_io.shar.Z

I also wrote a paper describing some of these problems.  It is
"Packet-Oriented Communications Using a Stream Protocol --or-- Making
TCP/IP on Berkeley UNIX a Little More Pleasant to Use", NISTIR
90-4232, January 1990" and is available from:

Mary Lou Fahey
NIST
Bldg 220, Rm A-127
Gaithersburg, MD  20899
fahey@cme.nist.gov

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes