Transport Interfaces Programming Guide

Chapter 1 Introduction to Network Programming Interfaces

This chapter is a high-level introduction to this book. It is most helpful to those who are new to network programming and for those who would like a brief overview of network programming in the Solaris environment.

Note -

Because this chapter briefly introduces these topics, you might find the reference books listed in "Related Books" to be helpful.

The Client-Server Model

The client-server model is a common method of implementing distributed applications. Figure 1-1 shows a typical networked environment where different services are provided and used by client and server processes.

Figure 1-1 Client-Server Model

A server is a process that provides a service that can be used by other processes. Servers accept requests, perform their service, and return the results to the requester. Some examples of servers are:

A file service such as the NFS^TM file system, which provides access to files and directories to other processes or systems
A display service, such as the X Window System^TM environment, which provides access to a high resolution display device
A time-of-day server that returns the current time whenever a client requests it

A server process normally listens at a well-known address for service requests. When a request is received, the server is unblocked and processes the client's request. Multiple servers can offer the same service, and they execute on the same machine or on multiple machines. It is common to replicate copies of a given server onto physically independent machines to increase reliability or improve performance. If a machine's primary purpose is to support a particular server program, the term "server" can be applied to the machine as well as to the server program. Thus, you hear statements such as "Mosey is our mail server."

A client is a process that makes use of a service, or services, provided by other processes and waits for a response. An individual system might be both a client and a server for different services, or even for the same service. For example, a print server receives print requests from a client, but might need to issue a client request to a file server to access a file.

Network Services in the Solaris Environment

The Solaris environment provides a large number of networking services based upon the Internet protocol suite (also loosely referred to as the TCP/IP protocol suite, described on "TCP/IP Internet Protocol Suite"). These services are listed in Table 1-1.

Table 1-1 TCP/IP Services


Service	Service Description
ARP	Address Resolution Protocol. Used to obtain the hardware network address corresponding to an IP address.
DHCP	Dynamic Host Configuration Protocol. Allows a host to get an Internet Protocol (IP) address and other Internet configuration parameters without any need for preconfiguration by the user.
BOOTP	Boot Protocol. Allows diskless systems to boot from a remote server.
DNS	Domain Name System. Name service used by the Internet. Uses both TCP and UDP protocols.
FTP	File Transfer Protocol. Reliable file transfer. Allows interactive transfer of ASCII and binary files.
ICMP	Internet Control Message Protocol. Used to relay error and control information. Used by TCP for flow control.
IP	Internet Protocol. The core protocol of the TCP/IP protocol suite.
NTP	Network Time Protocol. Synchronizes the system clock of your host with the system clock of another computer or time source.
RARP	Reverse Address Resolution Protocol. Used primarily in diskless clients systems that have a hardware address but need to find out their IP address.
SMTP	Simple Mail Transfer Protocol. Electronic mail delivery protocol.
SNMP	Simple Network Management Protocol. Basis of many network management packages. Allows monitoring of activity throughout a network.
TCP	Transmission Control Protocol. Reliable connection-oriented byte stream transport.
TELNET	Terminal emulation. Enables login and interactive session on a remote system.
TFTP	Trivial File Transfer Protocol. Simpler but less secure version of FTP.
UDP	User Datagram Protocol. Unreliable connectionless datagram transport.

In addition to the base protocols and services, the protocol suite also provides some commonly used utility applications (such as rcp, rsh, and rlogin) built on top of the Internet protocol suite.

The Solaris computing environment also provides heterogeneous distributed computing facilities in its ONC+ architecture. The ONC+ architecture is a set of services built on top of Sun's remote procedure call (RPC) protocol. The programming interfaces available in the ONC+ platform are described in the ONC+ Developer's Guide.

Layered Protocols

A protocol is a set of rules and conventions that describe how information is to be exchanged between two entities. Networking tasks often require more than one protocol to perform a task, such as file transfer.

These protocols are often conceptualized in a model consisting of a series of layers, each of which deals with one functional aspect of the communication. Each layer has a well-defined interface to the layer immediately above and below it. The left side of Figure 1-2 shows that data is passed down through the interface to the layer below. Each layer adds the necessary information to the data so that the receiving system understands how to handle the data and is able to route the data. At the bottom layer on the sending side, the data is physically transmitted across some medium to the receiving system. It is passed up through the layers on the right side of Figure 1-2, with each layer removing the information added by the corresponding layers on the sending system. A set of protocols layered in this way is called a protocol stack. A layer can have more than one protocol defined for it.

Figure 1-2 Layered Protocols

Two well-known reference models are discussed in the following sections: open systems interconnection (OSI) reference model and Internet (TCP/IP) protocol suite.

Open Systems Interconnection (OSI) Reference Model

The OSI reference model is used to conceptualize network service architectures and as a convenient framework for explaining networking concepts. It is not the basis for the Internet protocol suite, but the Internet protocol's four-layer model can be mapped to the more general OSI reference model. The OSI protocol suite follows the OSI reference model closely.

The OSI reference model divides networking functions into seven layers, as shown in Figure 1-3. Each protocol layer performs services for the layer above it. The ISO definition of the protocol layers gives designers considerable freedom in implementation. For example, some applications skip the presentation and session layers (layers 5 and 6) to interface directly with the transport layer. In this case, the application performs any needed presentation and session services.

Industry standards have been or are being defined for each layer of the reference model.

Figure 1-3 OSI Reference Model

OSI Reference Model Description

The following section explains each layer the OSI reference model.

Layer 1: Physical Layer

This layer specifies the physical media connecting hosts and networks, and the procedures used to transfer data between machines using a specified media. This layer is commonly referred to as the hardware layer of the model.

Layer 2: Data Link Layer

This layer manages the reliable delivery of data across the physical network. For example, it provides the abstraction of a reliable connection over the potentially unreliable physical layer.

Layer 3: Network Layer

This layer is responsible for routing machine-to-machine communications. It determines the path a transmission must take, based upon the destination machine's address. This layer must also respond to network congestion problems.

Layer 4: Transport Layer

This layer provides end-to-end sequenced delivery of data. It is the lowest layer that provides applications and higher layers with end-to-end service. This layer hides the topology and characteristics of the underlying network from users. It provides reliable end-to-end data delivery if the service characteristics require it.

Layer 5: Session Layer

This layer manages sessions between cooperating applications.

Layer 6: Presentation Layer

This layer performs the translation between the data representation local to the computer and the processor-independent format that is sent across the network. It can also negotiate the transfer formats in some protocol suites. Typical examples include standard routines that compress text or convert graphic images into bit streams for transmission across a network.

Layer 7: Application Layer

This layer consists of the user-level programs and network services. Some examples are telnet, ftp, and tftp.

TCP/IP Internet Protocol Suite

TCP/IP is a widely used protocol suite for internetworking, a term that refers to the connection of various physical networks to form one large virtual network. Any system connected to a TCP/IP internetwork should be able to communicate with any other system within the internetwork, regardless of the physical network on which the systems actually reside. Networks are linked together by a system that functions as a gateway between systems.

While TCP/IP has a closely associated history with UNIX systems, the TCP/IP protocols themselves are independent of the operating system, the network topology, and the connection medium. TCP/IP operates on Ethernet and Token Ring local area networks (LANs), across wide area links such as X.25, and serial connections. Support for TCP/IP networking has been an integral part of SunOS in all versions of the operating system.

TCP/IP Protocol Stack

The TCP/IP protocol suite can be described using a reference model similar to the OSI reference model. Figure 1-4 shows the corresponding OSI layers and some example services at each layer. TCP/IP does not delineate the presentation and session layers as the OSI model does; application code provides the necessary presentation or session functionality.

The TCP/IP protocols are defined in documents called Requests for Comments (RFCs). RFCs are maintained by the Network Information Center (NIC), the organization that handles address registration for the Internet.

RFCs define a number of applications, the most widely used being telnet, a terminal emulation service on remote hosts, and ftp, which allows files to be transferred between systems.

Figure 1-4 TCP/IP Protocol Stack

TCP/IP Protocol Stack Description

The following sections describes the parts of the TCP/IP protocol stack.

Device Drivers

The device driver layer (also called the Network Interface) is the lowest TCP/IP layer and is responsible for accepting packets and transmitting them over a specific network. A network interface might consist of a device driver or a complex subsystem that uses its own data link protocol.

Internet Protocol (IP) Layer

The Internet Protocol layer handles communication from one machine to another. It accepts requests to send data from the transport layer along with an identification of the machine to which the data is to be sent. It encapsulates the data into an IP datagram, fills in the datagram header, uses the routing algorithm to determine how to deliver the datagram, and passes the datagram to the appropriate device driver for transmission.

The IP layer corresponds to the network layer in the OSI reference model. IP provides a connectionless, "unreliable" packet-forwarding service that routes packets from one system to another.

Transport Layer

The primary purpose of the transport layer is to provide communication from one application program to another. The transport software divides the stream of data being transmitted into smaller pieces called packets in the ISO terminology and passes each packet along with the destination information to the next layer for transmission.

This layer consists of Transport Control Protocol (TCP), a connection-oriented transport service (COTS), and the user datagram protocol (UDP), a connectionless transport service (CLTS).

Application Layer

The application layer consists of user-invoked application programs that access services available across a TCP/IP Internet. The application program passes data in the required form to the transport layer for delivery.

Connection-Oriented and Connectionless Protocols

A number of characteristics can be used to describe communications protocols. The most important is the distinction between connection-oriented transport services (COTS) and connectionless transport services (CLTS).

Connection-Oriented Protocols

TCP is an example of a connection-oriented protocol. It requires a logical connection to be established between the two processes before data is exchanged. The connection must be maintained during the entire time that communication is taking place, then released afterwards. The process is much like a telephone call, where a virtual circuit is established--the caller must know the person's telephone number and the phone must be answered--before the message can be delivered.

TCP/IP is also a connection-oriented transport with orderly release. With orderly release, any data remaining in the buffer is sent before the connection is terminated. The release is accomplished in a three-way handshake between client and server processes. The connection-oriented protocols in the OSI protocol suite, on the other hand, do not support orderly release. Applications perform any handshake necessary for ensuring orderly release.

Examples of services that use connection-oriented transport services are telnet, rlogin, and ftp.

Connectionless Protocols

Connectionless protocols, in contrast, allow data to be exchanged without setting up a link between processes. Each unit of data, with all the necessary information to route it to the intended destination, is transferred independent of other data packets and can travel over different paths to reach the final destination. Some data packets might be lost in transmission or might arrive out of sequence to other data packets.

UDP is a connectionless protocol. It is known as a datagram protocol because it is analogous to sending a letter where you don't acknowledge receipt.

Examples of applications that use connectionless transport services are broadcasting and tftp. Early implementations of NFS used UDP, whereas newer implementations prefer to use TCP.

Choosing Between COTS and CLTS

The application developer must decide which type of protocol works best for the particular application. Some questions to ask are:

How reliable must the connection be?
Must the data arrive in the same order as it was sent?
Must the connection be able to handle duplicate data packets?
Must the connection have flow control?
Must the connection acknowledge the messages it receives?
What kind of service can the application live with?
What level of performance is required?

If reliability is paramount, then connection-oriented transport services (COTS) is the better choice.