|
|
Two basic kinds of service are provided for application programs: a connection-oriented service, in which a ``virtual circuit'' is established through the network between a pair of communicating programs, and a connectionless or ``datagram'' service, in which individual packets can be sent over the network to arbitrary addresses without the establishment of a virtual circuit. Generally, the connection-oriented service is between a pair of programs and guarantees reliable delivery of data, in the order it was sent. The connectionless service is usually described as an ``unreliable'' service because the datagrams are sent without the assumption that they will be received and reassembled reliably (datagrams may be discarded). Also, the connectionless service allows packets to be broadcast to multiple destinations, while the connection-oriented service is strictly between two endpoints.
The connection-oriented service is provided in TCP/IP
using TCP;
it can be accessed by opening the device
/dev/inet/tcp.
The service provided by this device
is of the type T_COTS_ORD:
a connection-oriented transport service
with orderly termination of connections.
This device is a ``cloning'' device.
This means that there is one pathname,
but each time the device is opened, a unique
minor device is accessed.
Thus, each minor device becomes what is known as a
Transport Service Access Point (TSAP).
The connectionless service is provided using the UDP protocol. It can be accessed by opening the device /dev/inet/udp, which is also a cloning device. The type of service provided by this device is T_CLTS.
The t_open function returns a structure containing a number of parameters (such as the maximum packet size) that further determine the behavior of these drivers as transport providers within the context of TLI. The precise values of these parameters are not discussed here.
The directory /dev/inet contains other device names in addition to /dev/inet/tcp and /dev/inet/udp; however, these other devices do not provide standard transport-layer services and so should not be accessed using TLI. In the future, other devices may be provided that can be used with TLI to provide different transport-layer services than TCP and UDP.