Path: utzoo!attcan!uunet!cs.utexas.edu!longway!std-unix
From: guy@auspex.uucp (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Recent Standards Activities
Message-ID: <782@longway.TIC.COM>
Date: 3 Jul 90 18:12:00 GMT
References: <770@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Auspex Systems, Santa Clara
Lines: 28
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From:  guy@auspex.uucp (Guy Harris)

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented.

Standard I/O, and "fgets()"/"fputs()" in particular, are
record-oriented?  News to me; I thought standard I/O offered byte
streams, and "fgets()" read stuff from that stream until it hit a
newline or EOF, and "fputs" put bytes from a string out onto that
stream.

For that matter, raw magtapes are also record oriented, and "read()" and
"write()" work fine on them.  I don't see the problem with TPn; a single
"write()" could either be turned into one packet, or broken up
arbitrarily into N packets if there's a maximum packet size.  If you
*want* to have a correspondence between "send it" calls and records, I
see no problem with providing additional calls to do that, but I also
don't see any problem with hiding record boundaries, if necessary, from
applications that *want* to just send byte streams over TPn.

>What does it mean to seek() on a network endpoint?

What does it mean to "seek()" on a tty?

Volume-Number: Volume 20, Number 96