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 Digital UNIX's network programming environment by focussing 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

Component	Interface	Description
Data Link Interfaces	Data Link Interface (DLI)	Allows programs written to DLI on the ULTRIX operating system to use DLI on the Digital UNIX operating system to access the data link layer. Digital UNIX provides DLI for backward compatibility with ULTRIX. See Appendix E. Appendix E
	`dlb` interface	Kernel-level interface targeted for STREAMS protocol modules that either use or provide data link services. The `dlb` STREAMS pseudodriver implements a subset of the Data Link Provider Interface (DLPI). See Chapter 2 and the Data Link Provider Specification (`dlpi.ps`) located in the `/usr/share/doclib/dlpi` directory. Note that the OSFPGMK200 subset must be installed to access the DLPI specification online.
Application Programming Interfaces	Sockets	The de facto industry standard programming interface. Digital UNIX implements the 4.3BSD socket interface as its default. You can use a special option to access the 4.4BSD interface. The Internet Protocol Suite, which consists of TCP, UDP, IP, ARP, ICMP, and SLIP is implemented over sockets. See RFC 1200: IAB Protocol Standards and Chapter 4.
	STREAMS	A kernel mechanism that supports the implementation of device drivers and networking protocol stacks. The STREAMS framework defines interface standards for character input and output within the kernel as well as between the kernel and user levels. The Digital UNIX operating system provides an AT&T, System V Release 4.0 compatible version of STREAMS. See Chapter 5.
	XTI/TLI	A protocol independent, transport layer application interface that consists of a series of functions. XTI is based on the Transport Layer Interface (TLI) and the transport service definition for the Open Systems Interconnection (OSI) model. See Chapter 3 Chapter 3 and the X/Open Portability Guide Networking Services, Part 7.
	eSNMP	A set of routines that enables you to extend the SNMP agent process by creating MIBs. See Chapter 6.
Communication Bridges Between STREAMS and Sockets	`ifnet` STREAMS module	Allows STREAMS-based network device drivers to access the sockets-based TCP/IP protocol stack provided on Digital UNIX. See Chapter 7.
	`dlb` pseudodriver	Allows applications that use STREAMS-based protocol stacks to access BSD-based drivers. The `dlb` pseudodriver implements a subset of the DLPI specification. See Chapter 7.

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 Digital UNIX 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 Digital 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, Digital UNIX's dlb pseudodriver, and the supported primitives.

1.2 Sockets and STREAMS Frameworks

The Digital 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

The dotted lines in Figure 1-1 indicate a supported configuration but not one that is provided by Digital UNIX.

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.

Note
Digital UNIX does not provide any STREAMS-based transport providers.

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:

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
Digital UNIX does not provide any STREAMS-based transport providers.
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 Digital 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 on the Digital UNIX system.

1.5 Sockets and STREAMS Interaction

Digital UNIX provides the ifnet STREAMS module to allow programs using Digital UNIX's 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 Digital UNIX.

Figure 1-3 illustrates an application using the BSD-based TCP/IP provided on Digital UNIX 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.