3.1 The Transport Driver Interface (TDI)

Figure 3.1 shows the general relationship between TDI clients and transport drivers.

Figure 3.1 TDI Clients and Transport Providers

As this figure shows, the Transport Driver Interface (TDI) defines a kernel-mode network interface that is exposed at the upper edge of all Windows NT transport protocol stacks. The highest level protocol driver in every such stack supports the TDI interface for still higher level kernel-mode network clients.

This interface includes the following:

Requiring that all Windows NT transport drivers expose a single common interface (TDI) simplifies the task of transport driver development in that all transports need code to support only a single defined interface. It also simplies the task of client development by minimizing the amount of transport-specific code that must be written.

Windows NT includes interface modules for several popular network interfaces, such as NetBIOS and Windows Sockets. Each of these interface modules exposes a native set of primitive functions, which are accessible through standard calls from user mode. When called, the interface module maps the native (frequently user-mode) function and its associated parameters and procedural rules, to one or more calls to the underlying TDI transport driver.

Key features of TDI include the following:

High Level of Granularity
TDI accommodates all primitives and conventions from existing popular network interfaces because it is relatively granular in nature, with several small TDI-defined requests that can be mixed and matched to accommodate mapping from existing network-interface functions.
Asynchronous Operation
Most kernel-mode TDI operations are asynchronous, using client-supplied callback routines to indicate asynchronous network events as they occur and completing most client-initiated operations submitted as IRPs asynchronously as well.
32-bit Addressing and Values
Like all Windows NT kernel-mode components, TDI transports and their clients are 32-bit code. All TDI-defined structures and parameters use 32-bit pointers and values.
Flexible Addressing Scheme
TDI does not mandate any particular address format, such as the 16-character NetBIOS name defined for legacy operating systems. Instead, it features an extensible mechanism by which many address formats can be identified and used.
Extensible Communication
TDI defines a TDI_ACTION IOCTL request that any TDI transport can use to support a set of transport-determined operations initiated by requests from its clients. This allows the client to submit transport-specific requests to the underlying transport driver that are not expressly defined by TDI.
Event Notification
TDI defines a scheme by which transports can notify their clients of interesting events that occur on the network without requiring the client to submit an explicit I/O request. For certain types of events, such as connects, disconnects, and receives, the transport driver can indicate data along with the event notification when it calls its client with such a notification.

The following features can be supported by a TDI transport driver as additional options:

Data Transfer Modes
TDI supports sending and receiving data as discrete messages (message mode) or as a stream of bytes (byte-stream mode). Support for either mode (or both) depends on the transport driver writer and/or on the nature of the protocol.
Internal Buffering
TDI transports can buffer their client's sends and receives internally. Transport-internal buffering allows the TDI client to set and query driver internal buffer sizes, request nonblocking send operations, receive notification of available buffer space, and look at (peek) buffered data before receiving it.
Management Options
All transports maintain some TDI-defined state about their respective features, limits, and runtime statistics. This allows each client to dynamically query and, in some cases to set, transport-provider static information, statistics, and configuration parameters. In addition, the extensible TDI_ACTION IOCTL, mentioned previously, allows any TDI transport driver to implement unique network-management features that can be accessed by its clients through action requests to the transport.
Quality of Service (QOS)
TDI transports can provide QOS negotiation upon establishment of a network connection. In addition, such a driver can support QOS for connectionless datagram transmission. To support either, TDI-defined connection-establishment and datagram-send requests include Options and OptionsLength parameters that allow a TDI client to include a transport-specific, variable-length counted string specifying QOS options.

In fact, the Options and OptionsLength parameters can be used to pass any transport-specific connection- or datagram-related options to the transport driver at the discretion of the driver writer, not just QOS specifications.

Expedited Delivery
When sending messages, the client can flag particular messages as expedited. At the sending side, the underlying transport sends these messages ahead of non-expedited messages. At the receiving side, expedited messages are indicated to the client before and/or separate from non-expedited messages.
Chained Receive Indications
If the underlying NDIS drivers support multipacket receive indications, a TDI transport can give its clients direct read-only access to a full TSDU in a single call, and the client can retain control of the buffer containing the TSDU until it has consumed the indicated data. This feature improves the performance of both transport and client by cutting down on call overhead for receive indications.