Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!VIOLET.BERKELEY.EDU!minshall
From: minshall@VIOLET.BERKELEY.EDU
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: standard interface
Message-ID: <8711140117.AA08165@violet.berkeley.edu>
Date: Fri, 13-Nov-87 20:17:37 EST
Article-I.D.: violet.8711140117.AA08165
Posted: Fri Nov 13 20:17:37 1987
Date-Received: Sun, 15-Nov-87 11:54:06 EST
References: <301@halley.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 27


    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).

    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.

    (By the way, absolutely no one, I predict, is going to want the
*semantics* of the "out-of-band" data from 4.2/4.3.  It is unreliable
for many applications; ie: it can drop data bytes from the TCP stream.
But, this is part of the "socket standard".  Oh, sigh, I'm just grumbling...)

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

Greg Minshall