Path: utzoo!mnetor!uunet!seismo!lll-tis!ati.tis.llnl.gov!narayan
From: narayan@ati.tis.llnl.gov (Narayan Mohanram)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TLI sockets comparison (paper promised).
Message-ID: <21899@tis.llnl.gov>
Date: 15 Dec 87 23:45:41 GMT
References: <21852@lll-tis.arpa> <1062@kulcs.UUCP>
Sender: nobody@tis.llnl.gov
Reply-To: narayan@ati.tis.llnl.gov (Narayan Mohanram)
Organization: Lawrence Livermore National Laboratory, Livermore CA
Lines: 49
Keywords: TLI sockets

In article <1062@kulcs.UUCP> dannyb@kulcs.UUCP (Danny Backx) writes:
>
>After studying your paper on TLI/sockets comparison, I had some questions
>and remarks.
>
>1. You talk about receiving data in the t_listen primitive.
>   I'm not sure I understand this.
>   What's the difference between that, and reading the first bunch of data
>   send over the connection ?

This was put in to satify people who only wanted to send a few bytes of
data, without actually going through the overhead of connection establishment.
The server could look at the connection data, and decide not to accept the
connection request. (Came from X.25 background I think).
>
>2. You are quite correct in stating the lack of a choise in the accept-primitive
>   for sockets.
>   It remains to be seen whether this feature is useful, though.
>   I can't think of many situations where one would want to reorder the
>   connection attempts, for giving priority to some-one specific maybe ???
>
>   What you CAN do with the socket interface is accepting the connections one
>   by one, then looking who is on the other side, and closing the
>   connection immediately if you don't like that guy.
>
An example would be an telnet server who would for security purposes not
accept any connections that came from some certain network or certain
class of machines. The differnce is the type of error that the client would
get. In the TLI case he could only get CONNECTION REFUSED.

>4. Why would anyone want to send partial records ?
>   You can always write buffering routines, very much like stdio, to
>   simulate sending partial packets in the application, while the transport
>   interface always gets complete packets.
>   (This is really a LOW level and application dependent matter, which
>   shouldn't be mixed with transport level stuff.)

How about the other side of the picture, and read partial records. It may
be important to know if there is more data available on this record. Also
machines with not much memory to spare can send partial packets without
actually buffering the entire packet. Buffering the entire packet would
involve an extra copying step. In the TCP/IP case the data could actually
be presented to the user without the PUSH bit arriving, and simply telling
the user that there is more in this record. (I don't think the TCP czar's
would like that though).

Narayan Mohanram

narayan@ati.tis.llnl.gov