1    Introduction to the Network Programming Environment

The network programming environment includes the programming interfaces for application, kernel, and driver developers writing network applications and implementing network protocols. Additionally, it includes the kernel-level resources that an application requires to process and transmit data, some of which include libraries, data structures, header files, and transport protocols.

This chapter introduces network programming environment by focusing on how the data link and application programming interfaces work to get data from an application in user space, through the network layers in kernel space, out onto the network, and back again.

Information about the kernel resources that support the interfaces is included in later chapters in this book. Individual chapters describe the particular system and library calls, data structures, and other programming considerations for each interface.

The primary components of the network programming environment are summarized in Table 1-1.

Table 1-1:  Components of the Network Programming Environment

It is easiest to understand the network programming environment by examining each component. The following sections introduce the environment piece by piece, starting with the components closest to the network and working up.

1.1    Data Link Interfaces

The network programming environment supports both the Data Link Interface (DLI) and the Data Link Provider Interface (DLPI). DLI enables you to port programs that run on ULTRIX systems to Tru64 UNIX systems. See Appendix E for information about DLI.

DLPI is a kernel-level interface that maps to the data link layer of the OSI reference model. DLPI frees its users from specific knowledge of the characteristics of the data link provider, allowing them to be implemented independently of a specific communications medium. Chapter 2 describes in greater detail DLPI, the Tru64 UNIX dlb pseudodriver, and the supported primitives.

1.2    Sockets and STREAMS Frameworks

The Tru64 UNIX operating system supports AT&T's System V Release 4 STREAMS and BSD sockets frameworks for writing networking applications and for doing kernel-level network input/output (I/O). A framework comprises a particular programming interface and the kernel-level resources that the system requires to transmit and receive data.

Sockets is the de facto industry standard interface for writing networking applications. The sockets framework is BSD-based, consisting of a series of system and library calls, header files, and data structures. Applications can access kernel-resident networking protocols, such as the Internet Protocol suite, through socket system calls. Applications can also use socket library calls to manipulate network information; for example, mapping service names to service numbers or translating the byte order of incoming data to that appropriate for the local system's architecture.

The STREAMS framework provides an alternative to sockets. The STREAMS interface was developed by AT&T and consists of system calls, kernel routines, and kernel utilities that are used to implement everything from networking protocol suites to device drivers. Applications in user space access the kernel portions of the STREAMS framework using system calls such as open, close, putmsg, getmsg, and ioctl. Figure 1-1 illustrates the STREAMS and sockets frameworks.

Figure 1-1:  Sockets and STREAMS Frameworks

Note

Tru64 UNIX supports, but does not provide any STREAMS-based transport providers (the dotted line portion of in Figure 1-1.

With sockets, the application in user space passes data to the appropriate socket system calls, which then pass it to the network layer. Finally, the network layer passes it, via the ifnet layer, to the BSD driver, which puts it on to the network.

With STREAMS, the application in user space passes data to the Stream head, which passes it to any STREAMS modules that have been pushed on the Stream to process it. Each module passes the data to the next module until it finally reaches the STREAMS driver, which puts it out on to the network.

1.3    X/Open Transport Interface

The X/Open Transport Interface (XTI) defines a transport layer application interface that is independent of any transport provider. This means that programs written to XTI can be run over a variety of transport providers, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The application specifies which transport provider to use.

Because XTI provides an interface that is independent of a transport provider, application developers are encouraged to write programs to XTI instead of STREAMS or sockets. Figure 1-2 illustrates the interaction between XTI and the STREAMS and sockets frameworks.

Figure 1-2:  XTI, STREAMS, and Sockets Interactions

Depending on the transport provider specified by the application, data can flow along one of two paths:

1. If a STREAMS-based transport provider is specified, data follows the same route that it did for an application written to run over STREAMS. It passes first through the Stream head, then to any modules that the application pushed onto the Stream, and finally to the STREAMS driver, which puts it on to the network.

   Note

   Tru64 UNIX does not provide any STREAMS-based transport providers.

2. If a socket-based transport provider is specified (TCP or UDP), data is passed through timod and xtiso. The appropriate socket layer routines are called and the data is passed through the Internet protocols and ifnet layer to the BSD-based driver, which puts it on to the network.

1.4    Extensible SNMP

The Tru64 UNIX SNMP agent provides a framework for extensibility (called eSNMP). The SNMP daemon functions as an extensible master agent, communicating with various subagents via the eSNMP protocol. The master agent implements the SNMP on behalf of the entire system, while subagents provide the actual MIB instrumentation. The eSNMP subagent development tools and API provide the mechanism for users to develop subagents that communicate with the master agent and extend the MIB view.

1.5    Sockets and STREAMS Interaction

The ifnet STREAMS module allows programs using Tru64 UNIX BSD-based TCP/IP to access STREAMS-based drivers. It provides the dlb pseudodriver to allow programs using a STREAMS-based protocol stack to access BSD-based drivers provided on Tru64 UNIX.

Figure 1-3 illustrates an application using the BSD-based TCP/IP provided on the operating system and accessing a STREAMS-based driver.

Figure 1-3:  Bridging STREAMS Drivers to Sockets Protocol Stacks

In Figure 1-3, data travels from a sockets-based application through the appropriate sockets system calls and is processed by the Internet protocols. Then the BSD ifnet layer of the networking subsystem, whose function is to map BSD ifnet messages to DLPI, passes the data to the ifnet STREAMS module. The ifnet STREAMS module processes it so that the STREAMS driver can put it on to the network. When information for the sockets-based application is returned, the STREAMS driver picks it up off of the network and passes it to the DLPI interface of the ifnet STREAMS module. The DLPI interface of the ifnet STREAMS module translates DLPI messages to BSD ifnet and passes it back to the BSD ifnet layer. The data is then processed by the Internet protocols and passed back to the application.

Figure 1-4 illustrates an application using a STREAMS-based protocol stack and accessing a BSD-based driver.

Figure 1-4:  Bridging BSD Drivers to STREAMS Protocol Stacks

In Figure 1-4, data travels from a STREAMS-based application through the Stream head and is processed by whatever Streams modules have been pushed onto the stack. Instead of finally being passed to a STREAMS driver, the data is passed to the dlb STREAMS pseudodriver and is then forwarded to the ifnet layer of the sockets framework. From there it is further processed by a BSD driver and put on to the network.

1.6    Putting It All Together

Figure 1-5 represents the entire network programming environment. Variations of this figure appear in each chapter to give you perspective on the information being presented.

Figure 1-5:  The Network Programming Environment