The Transport Driver Interface (TDI) specification in Windows describes the set of primitive functions by which transport drivers, TDI clients, and the network file and print redirector communicate. The TDI specification also discusses the call mechanisms used to access transport drivers, TDI clients, and the network file and print redirector.

All Windows transport providers expose TDI, which operates in kernel mode only at the upper edge of the transport protocol stack. In other words, it sits above all other transport stack components and is the primary interface used by higher-level components, such as Windows Sockets 2, to communicate with the transport stack.

Because the programmer must determine the format and meaning of messages, TDI can be complicated to use. Application programmers generally program to the Application Programming Interface (API) of a TDI client, such as Windows Sockets 2 or NetBIOS, rather than to TDI itself. Occasionally, such as when needing to change fields in the TCP packet header, the programmer might require lower-level access to raw packet data than is provided by interfaces such as Windows Sockets 2. In those cases, TDI can be accessed directly to achieve the desired functionality.

TDI Features

TDI supports:

• Most Windows Server 2003 transport providers.
• An open naming and addressing scheme.
• Message and stream-mode data transfer.
• Asynchronous operation.
• Unsolicited event indication.
• The ability for extensibility clients to submit private requests to a transport driver that understands these requests.
• Limited use of standard kernel-mode I/O functions to send and receive data.
• Thirty-two–bit addressing and values.
• Access control lists (ACLs)—used for security—on TDI address objects.

For more information about TDI, see TDI Transports and Their Clients section on the Microsoft Developer Network (MSDN).

See Also

Host-to-Host Transport Layer, NDIS, Windows TCP/IP Stack