narayan@lll-ati.arpa (Narayan Moharram) (11/24/87)
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.
dannyb@kulcs.UUCP (Danny Backx) (12/03/87)
Narayan,
After studying your paper on TLI/sockets comparison, I had some questions
and remarks.
Since no-one else came up with them (to my great surprise), I decided
to post them :
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 ?
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.
3. I see the inability of TLI to determine who it's talking to as a grave
shortcoming.
This could have been the basis of a lot of protection schemes.
(See above.)
I feel it is quite elementary to be able to obtain that information.
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.)
I would appreciate your comments.
Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3537 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@kulcs.BITNET | Belgium narayan@ati.tis.llnl.gov (Narayan Mohanram) (12/16/87)
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