Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!im4u!esc-bb!halley!bc
From: bc@halley.UUCP (Bill Crews)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: standard interface
Message-ID: <304@halley.UUCP>
Date: Thu, 19-Nov-87 23:53:34 EST
Article-I.D.: halley.304
Posted: Thu Nov 19 23:53:34 1987
Date-Received: Sun, 22-Nov-87 11:01:43 EST
References: <301@halley.UUCP> <8711140117.AA08165@violet.berkeley.edu>
Reply-To: bc@halley.UUCP (Bill Crews)
Organization: Tandem Computers, Austin, TX
Lines: 51

In article <8711140117.AA08165@violet.berkeley.edu> minshall@VIOLET.BERKELEY.EDU writes:

>    Why aren't sockets the best thing in the world?  Well, for one thing,
>they can cause more copying of data than one would like.  This is true
>because the semantics of "send" is that, when the send returns, the "sent"
>buffer must be immediately usable by the application (so, that physical buffer
>can't be used as a queueing space for "not-yet-sent" TCP data.  Also,
>the "receive" operation does not pass control of the "receive" buffer
>to the transport layer beyond the duration of the "receive" call itself
>(so, that buffer can't be used to copy in data later received on
>the connection).

For PCs in real mode, this is a characteristic that one is stuck with, leaving
one with the choice between layer isolation and performance, to that degree.
With most hardware these days, one can diddle the page tables to "poof" the
data into kernel space without moving it.  But the PC lives on.  Sigh.

>    The above are the performance reasons.  There is also a semantics
>problem: sockets have socket-semantics, TCP has TCP-semantics.  The mapping
>between the two sets of semantics is fairly good, but not ideal (if
>even complete).  I would like a TCP interface with TCP semantics.  I would
>(like Bill Crews, and everyone else) like to see a sockets library.  My
>socket library, however, would map the sockets semantics to TCP semantics.

Uh, what does that mean?  What else would one do?  You aren't proposing
contaminating the socket interface with knowledge of the underlying transport,
are you?  Do you want a TCP interface or a transport-protocol-independent
interface, like sockets or TLI?

> [...]

>    In Bill Crews message (<301@halley.UUCP>), he mentions a TLI.
>I would like more information on this interface.

OK.  TLI is a part of Unix System V.3 network services.  I would imagine that
most V.3 manual sets will contain TLI documentation.  I've been using
the Unix System V Network Programmer's Guide for the AT&T 3Bs.  Other very
interesting reading can be found in the Unix System V STREAMS Programmer's
Guide and the STREAMS Primer.  Now, TLI doesn't imply STREAMS and STREAMS
doesn't imply TLI.  They are both good ideas, though, and are both implemented
in V.3.

Happy reading.

> Greg Minshall

-bc
-- 
Bill Crews                                   Tandem Computers
                                             Austin, Texas
..!rutgers!im4u!esc-bb!halley!bc             (512) 244-8350