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