Introduction to Winsock Kernel (WSK)
Overview of WSK
In Windows Vista a new transport-independent kernel mode Network Programming Interface (NPI) called Winsock Kernel (WSK) has been added. Using WSK, kernel-mode software modules can perform network communication using socket-like programming semantics similar to those supported in user-mode Winsock2. While the WSK NPI supports most of the same socket programming concepts as user-mode Winsock2 like socket creation, bind, connect, accept, send and receive, it is a completely new programming interface with unique characteristics such as asynchronous I/O that uses IRPs and event callbacks to enhance performance.
WSK was designed with the following goals in mind:
o Provide a simple to use, Winsock2-like interface to kernel mode developers.
oBetter expose the innovations made by the next generation TCP/IP stack in Windows Vista
o Improve scalability and efficiency by improving on the performance and memory limitations of previous Network Programming Interfaces (NPI). For example, WSK has improved socket creation performance and a smaller memory footprint per socket than past NPIs.
o Easy to port existing TDI clients to WSK. Components such as http.sys (kernel mode HTTP handler) within Windows Vista have ported from TDI to WSK with ease.
At the core of WSK is the WSK subsystem, which implements the WSK Provider NPI. At its upper edge, WSK exposes this provider implementation for use by WSK applications. At its lower edge, the WSK subsystem interfaces with transport providers such as the TCP/IP stack. WSK applications implement the WSK Client NPI and consume the WSK Provider NPI to perform network I/O operations.
Note: All components in the diagram above reside in the kernel
Some of the additional benefits in WSK include:
o Enhanced IPv6 support. WSK clients can use a single IPv6 socket to handle both IPv4 and IPv6 traffic. For example a single WSK listening socket can accept both IPv4 and IPv6 connections.
o Improved Serviceability. The WSK subsystem hides the intricacies of transport discovery and load/unload handling from the WSK clients. This allows the WSK subsystem to improve the system’s serviceability with minimal direct impact on WSK clients.
o Uniform support for standard options or IOCTLs across all transports
TDI and WSK
TDI is a widely used interface to interact with the network stack and intercept application traffic. Since prior to Windows Vista, the user mode Winsock2 API used the TDI interface to interact with TCP/IP. Kernel-mode TDI filter drivers were used by some software vendors to intercept all Winsock traffic before it was submitted to the TCP/IP stack. A TDI client also enabled a driver to send and receive data to/from the TCP/IP stack. Even though TDI has been a worthy predecessor for WSK for over a decade, it has shortcomings such as a sharp learning curve and performance bottlenecks.
In Windows Vista, WSK is the recommended NPI for performing network I/O in the kernel and the Windows Filtering Platform (WFP) is the recommended API for network filtering (replacement for TDI filter drivers). New kernel mode clients should opt to use WSK for network I/O instead of TDI because WSK is more flexible, easier to use, and offers much better performance. To take advantage of the next generation stack, existing TDI applications should move to WSK in the Windows Vista timeframe. On Windows Vista, TDI is still supported; however, it has been implemented using a translation layer and thus its performance is sub-optimal resulting in performance degradation for TDI clients. In addition, the capabilities that are available using TDI are going to be significantly more limited than through WSK as no new functionality is being developed for TDI.
WSK applications are not limited to the TCP/IP transport implemented in the next generation TCP/IP stack in Windows Vista. WSK allows its clients to use protocols implemented by TDI-based transports by translating WSK operations to TDI operations on behalf of the client for those TDI transports denoted by the client. This gives clients of WSK the convenience of a single NPI rather than using WSK for some protocols and TDI for others. WSK also allows TDI filters to intercept TCP/IP traffic to/from WSK clients to facilitate a smooth transition period during which software vendors move from TDI filters to WFP for performing network traffic filtering.
Additional Information
If you have any questions, comments or would like to obtain a copy of the WSK documentation and associated sample, please email wskapi@microsoft.com.
WSK bugs and feature suggestions can be submitted to the Microsoft bug database by joining the Windows Network Developer Platform (WNDP) program at the Microsoft Connect website: https://connect.microsoft.com.
Note: The WSK sample will not build in WDK build 5308 due to missing header files. This is a known issue and should be corrected in the Beta 2 WDK.
-- Mike Flasko