Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!lll-tis!lll-ati.arpa!narayan From: narayan@lll-ati.arpa (Narayan Moharram) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: TLI sockets comparison (paper promised). Message-ID: <21852@lll-tis.arpa> Date: Tue, 24-Nov-87 13:35:46 EST Article-I.D.: lll-tis.21852 Posted: Tue Nov 24 13:35:46 1987 Date-Received: Fri, 27-Nov-87 23:32:18 EST Sender: nobody@lll-tis.arpa Reply-To: narayan@lll-ati.arpa (Narayan Moharram) Organization: Lawrence Livermore National Laboratory, Livermore CA Lines: 300 Keywords: TLI sockets Since there were several request, I am posting this paper which was done in Jan 86. I think most of this stuff is still valid. (narayan@LLL-ATI.ARPA) +===============================================+ | | | Sockets / TLI | | | +===============================================+ Narayan Mohanram Gil McGrath Tom Faulhaber Sockets/TLI a comparison ======================== 1. Introduction 2. Objective 3. Differences/Similarities 3.1 Support of Protocols 3.2 Support of Architecture 3.3 Involvement of OS 3.4 Installed base 3.5 Migration path between interfaces. 3.6 Comparision of features/model 4. Conclusion 1. Introduction =============== There are two main UN*X programming interfaces available at this point for Networking Transport level access. a. Berkeleys Sockets b. AT&T's TLI. Sockets were introduced in Berkleys 4.1c release of the UN*X BSD system, and made popular in the 4.2 BSD release. They provide well known networking access for the DARPA services. TLI was presented to the P1003 committee last year, and is made available in AT&T's System 5 release 3.0 of the UN*X system. 2. Objective ============ It is not the intention of this work to pick the `better' mechanism of the two, but merely to point out the differecnces between the two, the similarities, and the different features. It is up to the committee to construe its opinion. It is also desirable to define a transport interface to UN*X as opposed to a heterogeneous network interface across operating systems. 3. Differences/Similarities =========================== Both Sockets, and the AT&T's Transport Level Interface, provide a mechanism for writing user level programs to access the underlying transport protocols. They both attempt to provide protocol independence, and program portablity to varying degrees. 3.1 Support of Protocols ======================== In comparing the two mechanism, on a protocol by protocol basis, it was found they they both support TCP, and XNS adequately. The Socket mechanism, however has some shortcomings in its ability to provide user data at connection initiation, and disconnection phases. As far as SNA is concerned, it is currently no immedeatly obvious that it cannot be supported by either of these two. 3.2 Support of Architecture =========================== Both Sockets and TLI support both virtual circuit, and datagram services. But it is not very clear if Sockets can support ISO's upper level services. TLI, on the other hand was developed with ISO as the background. It was designed to support session services. There are strong indications from AT&T that stands behind TLI, commitment for further development, and enhancements. It is not very clear at this point in time about on going efforts in the Socket model. 3.3 Involvement of OS ===================== The philosophy of Sockets is embedded in the UN*X kernel, and needs a lot of Networking support from the operating system. 3.4 Installed base ================== There is an extermly large intalled base of software that uses the Socket mechanism, both in the 4.x BSD, and in the System 5 world. TLI on the other hand has few installed sites (at the time of this writing), currently running on networks with this model. 3.5 Migration path between interfaces ===================================== It is possible to migrate code from Sockets to TLI very easily. It is also possible to go in the opposite direction. But with some protocols, there are several restrictions, or deviations from the Socket programmatic defenitions. 3.6 Comparision of features/model ================================= The various features/similarities and differences are summed up in the table below. +=========================================================================+ | | | | | Features | TLI | Sockets | +=========================================================================+ | | | | |Getting the | T_open call. Can open any| Socket call. Uses different | |Cookie | minor device, such as | parameters. Cannot access | | | /dev/net0, /dev/net1. | an already open minor dev. | | | Minor networking devices | (Exept if processes are | | | can be shared by unrela- | related). | | | ted processes | | | | | | --------------------------------------------------------------------------- |Connection | T_listen call. This can | | |Establishment | be done without accepting|Listen call, followed by an | | | a connection. Also one |an accept. This is necessary | | | can listen multiple times|as `listen' only sets the | | | without accepting a |queue length. | | | connection. | | | | |Accept call forces a connec- | | | The queue length for |tion to be accepted blindly. | | | incoming connections is | | | | Set in the t_bind call. | | | | | | | |Program Senario |Program Senario | | |=============== |=============== | | |t_bind(t_fd, Address, | | | | queue_length); |bind(socket, Address); | | |for(;;) { |listen(queue_length); | | | t_listen(t_fd, ret_adr)|for(;;) { | | | /* Hangs For CON.IND | new_connection = | | | * May or may not | accept(socket, | | | * Accept Connection */| ret_addr); | | | n_fd = t_open( | /* | | | "/dev/net", O_RDWR);| * Process new conn. | | | t_accept(n_fd, indic);| */ | | | /* | XXXX | | | * Process new Conn. |} | | | */ | | | | XXXX | | | |} | | | | | | | |T_connect() primitive, |Connect() primitive used for | | |is used for connection |for connection initiation. | | |initiations. | | | | | | | | |It is possible to connect | | |The network endpoint must |without being bound to a | | |be bound to a protocol |protocol address. The system | | |address before a t_connect|will pick one. | | |primitive can be used. | | +=========================================================================+ =========================================================================== +=========================================================================+ | | | | | Features | TLI | Sockets | =========================================================================== |Accepting |T_accept primitive. |Accept() primitive used. | |Connections |you have to allocate a |Accept returns a socket | | |file descriptor, upon |file descriptor. It is not | | |which the connection is |possible to select which | | |accepted. This gives the |connection request to | | |flexibility of accepting |accept. | | |the connection on the same| | | |file descriptor or any | | | |other selected minor | | | |device /file descriptor. | | | | | | | |T_accept also give the | | | |program the option of not | | | |accepting, or delaying the| | | |connection establishment | | | |(Multiple t_listens). | | | |It is possible to accept | | | |connection request in any | | | |order. | | --------------------------------------------------------------------------- |User Data |Can receive user data in |There is no concept of | |On Connection/ |the t_listen primitive. |sending or receiving user | |Disconnection |Can send data in both the |data on any of the connection| | |t_connect, and the |or disconnection primitives. | | |t_accept primitives. Can | | | |both send and receive data| | | |on all the disconnection | | | |primitives. This is only | | | |possible if the protocol | | | |permits such a concept. | | | |(Can be determined by | | | |t_getinfo). | | --------------------------------------------------------------------------- |Asynchronous |It is possible to send |Socktes have similair but | |Processing. |connection request, and |features. But errors after | |(Not the OS |recieve asynchrous notifi-|doing an asynchornous | | Features). |cation via t_sndconnect(),|operation are lost. | | |and t_rcvconnect(). |eg. | | | | | | | |An asynchronous connect(), | | | |followed by a select(), | | | |does not easily report, the | | | |type of error, that occured. | =========================================================================== +=========================================================================+ | | | | | Features | TLI | Sockets | =========================================================================== |Getting Address |It is not possible to |getsockname(), and | |information for |find out Connection |getpeername() primitives. | |an established |Address information. (It |These primitives give the | |connection |is possible to get the |address information that | | |connection status). |is associated with this | | | | | --------------------------------------------------------------------------- |Data Transfer |Record boundaries can be |There is no way of reading | | |specified by the MORE_flag|or writing partial records. | | |feature in describing the |(Record boundarires cannot | | |user record being written.|be specified). | | | | | --------------------------------------------------------------------------- |Urgent/ Out of |The only way to receive |The socket can be register | |band data. |urgent /out of band data, |to receive a SIGURG signal, | | |is to read all the data, |upon receipt of the urgent | | |then find out that there |data. It is then possible | | |is out of band data in |to receive the urgen data | | |the data queue. |separately (ahead of pending | | | |normal data). | | | | | |Should urgent/ | | | |Out of band data| | | |be presented to | | | |the user ahead | | | |of normal data ?| | | | | | | --------------------------------------------------------------------------- |Other Misc. |On System 5 R.3 streams, |Read/Write system calls work | | |One has to explicitly |directly on a socket. | | |push a "tirdwr" module in | | | |the path. Read/Write will | | | |fail otherwise. There is | | | |no clear way (implemen- | | | |tation independent) way | | | |to obtain a file descrip- | | | |tor for read/write. | | | | | | | |Standpoint | | | |========== | | | |Unix read/write semantics | | | |are associated with a file| | | |descriptor, and transport | | | |endpoints need not have | | | |this capability. | | +=========================================================================+ 4. Conclusion ============= Both sockets, and TLI have most of the basic capabilities necessary for networking. There is a great deal of overlap in the features. But there are certain difference, between the two, which mean that each methodology tends to favour, certain types of underlying protcols. It would be easily possible to add a few features to either, and obtain an interface, that does provide all the necessary networking primitives.