Transport Driver Interface

Transport Driver Interface
Name	Transport Driver Interface
Developed by	Microsoft
Initial release	Windows NT 3.5
Latest release	Windows 10 / Windows Server
Operating system	Microsoft Windows
License	Proprietary

Transport Driver Interface

The Transport Driver Interface is a kernel-level programming interface introduced for Microsoft Windows NT to enable development of network protocol drivers and transport-layer modules. It provides a stable contract between network interface card drivers, protocol stacks, and system components such as the Remote Procedure Call runtime, Winsock, and Server Message Block implementations. Designed in the era of Windows 95 and Windows NT 3.5, it interacts with subsystems including Internet Information Services, Active Directory, and virtualization technologies like Hyper-V.

Overview

TDI was created to allow modular integration of transport protocols such as Transmission Control Protocol, User Datagram Protocol, and vendor-specific transports for products like Microsoft SQL Server and Exchange Server. It exposed services consumed by higher-level subsystems including Windows Sockets, NetBIOS over TCP/IP, Terminal Services, and Distributed Component Object Model remoting. TDI interacts with Network Driver Interface Specification miniport drivers and cooperates with NDIS to facilitate packet flow. Over time, Microsoft introduced alternatives including the Windows Filtering Platform, Winsock Kernel, and the Windows Driver Foundation to supersede aspects of TDI.

Architecture and Components

The architecture centers on objects such as device objects, file objects, and IRP-based request flows used across Windows NT driver models. Key components include TDI providers, TDI clients, and TDI transports which interface with components like NetBT and TCP/IP stack. TDI defines entry points for operations including connect, send, receive, and disconnect that integrate with I/O Request Packet handling and the I/O Manager. Interaction with layered drivers mirrors patterns found in Installable File System drivers and Virtual DOS Machine subsystems. The interface relies on kernel constructs shared with Security Account Manager interactions and thread context switching handled by the Windows Scheduler.

Programming Model and APIs

TDI programming uses exports and IOCTL interfaces documented in legacy Windows Driver Kit releases and requires handling of IRP major/minor codes, completion routines, and synchronous/asynchronous semantics. Developers use functions similar to those in Device Driver Interface examples and follow synchronization strategies akin to Thread Pool and Work Item patterns. TDI API usage appears in drivers for products such as Microsoft Exchange, SQL Server, and third-party network appliance vendors like Cisco Systems and Intel Corporation. Debugging commonly uses tools from the Debugging Tools for Windows suite, integration with Event Tracing for Windows, and logging into Event Viewer channels.

Driver Development and Implementation

Driver authors historically used the Windows Driver Kit and samples provided by Microsoft Developer Network to implement TDI transports, often targeting specific hardware sold by Broadcom, Realtek, Marvell Technology Group, and Atheros. Implementations require correct handling of power management callbacks shared with ACPI and proper interaction with Plug and Play manager to enumerate network adapters. Best practices borrowed from Windows Hardware Lab Kit certification include correct IRQL management, use of KeRaiseIrql/KeLowerIrql patterns, and adherence to Driver Verifier checks. Commercial and open-source projects integrating TDI included drivers used by Citrix Systems, VMware, and Seagate Technology storage networking solutions.

Security and Access Control

TDI-based drivers must integrate with Windows security subsystems such as Local Security Authority protocols, Security Support Provider Interface, and access control described by Access Control List entries stored via Active Directory objects. Kernel-mode drivers using TDI need to respect token and privilege semantics originating from Authentication mechanisms like Kerberos and NTLM. Vulnerabilities in transport drivers have historically been vectors exploited by malware families tracked by Microsoft Security Response Center, prompting mitigations deployed via Windows Update and signatures by vendors like Symantec and Kaspersky. Modern replacements emphasize sandboxing and user-mode mediation present in Windows Filtering Platform and User-Mode Driver Framework to reduce attack surface.

Performance and Diagnostics

Performance tuning of TDI drivers involves careful buffer management, scatter/gather I/O strategies similar to those used in Direct Memory Access controllers, and leveraging Large Send Offload on NICs from vendors like Intel and Broadcom. Diagnostics utilize tools such as Performance Monitor, Network Monitor, and Message Analyzer while kernel debugging employs WinDbg and kernel trace sessions via Event Tracing for Windows. Bottleneck analysis often references counters exposed by Remote Desktop Services and applications like Microsoft Exchange which depend on transport efficiency. As networks scaled with Ethernet and InfiniBand deployments in datacenters run by Amazon Web Services and Microsoft Azure, drivers migrated toward newer frameworks to exploit features like RDMA and kernel bypass techniques used in high-performance computing clusters such as those at Lawrence Berkeley National Laboratory.

Category:Windows drivers