Section 3.2. The Windows NT Network Stack

   

---

3.2 The Windows NT Network Stack

Understanding the Windows NT network I/O stack is important for several reasons. A Windows NT client uses this network I/O stack to access resources controlled by a server and for data communications. In addition, with network-attached storage a situation often arises in which one server accesses resources controlled by another server. A good example is a Windows NT Web server application that, in response to a request from a client, makes a database call to retrieve some data and the database is running on a separate Windows NT SQL server. The Web server application accesses the SQL server using the Windows NT network I/O stack.

Figure 3.2 shows the Windows NT network I/O stack. Sections 3.2.1 through 3.2.6 describe the various components , starting from the bottom of the figure (and the I/O stack).

Figure 3.2. Windows NT Network Stack

The networking card is typically operated and controlled by an NDIS (Network Driver Interface Specification) “compliant driver. NDIS is architecture for decoupling network card drivers from higher-level network protocol stacks. The next layer up is the TCP/IP stack. The term TCP/ IP (which stands for "Transmission Control Protocol/Internet Protocol") is used loosely to refer to all the various components that play a role in networking and data communications, such as IP, DHCP (Dynamic Host Configuration Protocol), or TCP. The TCP/IP stack is not the focus of the discussion here. The next layer up is the Transport Driver Interface, described next.

3.2.1 Transport Driver Interface

Moving up a layer from the TCP/IP network protocol stack, one encounters the Transport Driver Interface (TDI). TDI defines an efficient kernel mode interface for network applications to request and receive services from network transports. It is implemented as a library that the kernel mode drivers link with. TDI allows for efficient network communication and attempts to reduce the number of times data is copied around ”for example, to/from an application buffer to/from a network transport protocol.

For example, TDI allows an application to register a callback, and when the application receives a data packet, the callback procedure specified is invoked. The callback procedure may simply look at the data packet, especially if it is short, and indicate that it is done with the data packet (and the transport may treat the packet as having been successfully delivered). If necessary, the client may cause the data packet to be copied into a buffer where it can look at it later.

3.2.2 Redirected Drive Buffering Subsystem

The next layer up is the Redirected Drive Buffering Subsystem, or RDBSS. As the name implies, RDBSS is responsible for providing buffering code for all redirectors. The RDBSS handles intricacies of interacting with the Windows NT Cache Manager on behalf of all network file systems. The RDBSS was first introduced with Windows 2000. Prior to that, all network file systems had to implement a full-fledged driver that also dealt with routine operating system interactions.

3.2.3 Mini-redirectors

Mini-redirectors implement functionality specific to a network file system or protocol and use the services of the RDBSS to handle routine interactions with the Windows NT operating systems. Several mini-redirectors ship with Windows 2000 and Windows XP:

• The CIFS mini-redirector ships with Windows 2000, Windows XP, and Windows Server 2003. Earlier versions of Windows NT implemented a monolithic redirector. The RDBSS code that is common to all mini-redirectors is implemented independently by each redirector vendor. CIFS is explained in detail in Section 3.3.

• The WebDAV (short for "Web Distributed Authoring and Versioning") mini-redirector supports HTTP 1.1 and the WebDAV extensions for reading and writing Web documents. It provides an ability that allows drive letters to be mapped to a server, no matter whether the server is an HTTP server or a CIFS server. Corporate firewalls are often set up to allow HTTP access, but they may not be set up to allow CIFS protocol requests and responses to pass through. Thus the WebDAV mini-redirector provides support for accessing HTTP servers through firewalls where the CIFS mini-redirector may fail. With XML and HTTP playing an ever increasing role, the importance of the WebDAV mini-redirector should only increase in the days to come. Note that WebDAV is a strictly client-to-server protocol and plays no role in server-to-server communication.

• The Windows NT Services for UNIX ( SFU ) product ships with a mini-redirector that implements the NFS protocol. NFS is described in Section 3.4.

3.2.4 Multiple Universal Naming Convention Provider

Windows provides a Universal Naming Convention (UNC) for accessing remote files. UNC support dates from MS-DOS 3.3 days, well before the advent of Windows NT. With UNC, an application can address a file relative to a server and a share (recall that a single server may have multiple shares). The UNC format is

\\ServerName\Share\SubDir1\......\SubDirN\FileName

The various versions of Windows differ in UNC support in terms of

• The maximum length of a UNC path

• The maximum length of each subcomponent ”for example, the subdirectory name

• The maximum size of the server name

To allow applications and utilities to use the services of network resources accessed via UNC style pathnames, Microsoft has built the Multiple UNC Provider (MUP).

Because Windows NT supports multiple network file systems, the MUP acts as a router, routing the request to the correct network file system, or more correctly, to the mini-redirector implementing that particular network file system. The routing is accomplished in one of two ways:

1. The MUP cache is checked to see if the server in question has been connected to before. In this case the same mini-redirector that provided the previous connection is used.

2. Each mini-redirector is polled in a defined order for UNC connections not in the cache.

3.2.5 Multi-provider Router

The multi-provider router (MPR) provides functionality similar to the MUP, routing application requests to the appropriate mini-redirector, but with two differences:

1. The MPR code runs in user mode rather than kernel mode.

2. The MPR provides functionality for applications that do not use UNC pathnames. One example is providing functionality for applications that use the WinINet APIs. WinINet stands for "Windows Internet," an application programming interface that provides an abstraction layer for applications to use standard Internet protocols such as HTTP, FTP, and Gopher.

The MPR is a dynamic link library provided by Microsoft with a well-defined interface at its bottom edge to which the vendor of the mini-redirector writes . This library is installed when the redirector is installed.

3.2.6 Client-Side Caching

The Windows 2000 CIFS mini-redirector implements a feature called client-side caching that allows for frequently used files to be cached locally within the client. The files cached could be documents like a Microsoft Word or Excel file, or they could be executable files ”for example, executable files associated with Microsoft Office applications. The caching is initiated in one of two ways:

1. The user explicitly requests caching.

2. The mini-redirector initiates caching when a file is opened.

Client-side caching provides for performance, scalability, and robustness. Clients can continue to work even when the server is unavailable because of problems at the server or within the network. The load on the servers is reduced, and a single server can cater to more clients . The client application runs faster because retrieving a file from a local disk is much faster than retrieving a file from the network.

Not just any file can be cached. Only files that are stored on a share (resource) that is explicitly marked cacheable (by the server administrator) can be cached. This information is conveyed to the CIFS mini-redirector in a Server Message Block (SMB) response. The SMB protocol was modified to convey information to the client indicating whether the files on the share are cacheable or not, and if cacheable, the exact nature of the caching the client should employ . This caching can be of three different types:

1. Shares where caching is enabled for documents only

2. Shares where caching is enabled for programs only

3. Shares where no caching of any kind is allowed

At press time, only Microsoft CIFS clients implement client-side caching. Non-Microsoft clients also cache files, but only when the client has a live connection to the server, and then only for files that the client has actively opened on the server. Client-side caching as implemented by the Windows client caches files even when the client is disconnected, and it caches files that have been opened in the past, but these files need not be actively open . Indeed, this cache of files on the client is accessible even when the client is disconnected from the server.

Windows 2000 client-side caching is designed to provide seamless functionality to Windows applications; that is, the caching is transparent to the application. Although the caching is also intended to be generally transparent to the user, the user is not isolated and needs to get involved with the synchronization and error handling required by client-side caching. In other words, when multiple clients have made conflicting changes to the same document in their respective caches, the user is notified of the conflict, and it is up to the user to take corrective action.

The various components that collectively provide the functionality include:

• The CIFS mini-redirector.

• An API supported by the CIFS mini-redirector and the associated user mode components that allow applications to administer and use the features offered .

• A user mode component that drags data from the server and writes it out to the locally cached file.

• A local database that tracks what is cached locally and its current state. An entry is created in this database for each share to which the client connects (that is marked cacheable), for each cacheable file that the client opens, and for any intervening directories between the file and the share. For each entry created in the database, the associated security information for the user and the guest user on the client is copied from the CIFS server. The database acts as a file system for locally cached files.

When a program file is first cached, it is marked as sparse and the local copy is gradually filled in as the application requests data from the server. When a document file is cached, it is also marked as sparse. All write commands are sent to the remote document first and also reflected in the local cached copy. A user mode agent runs in the background and gradually drags data from the share to the local cached copy. When a file is fully copied, the sparse marking is removed and the file may henceforth be used instead of the copy on the share.

If multiple clients may cache documents and edit them while in a disconnected state, the question arises as to how coherence is maintained between multiple clients. One simple way out is not to allow cached documents to be edited. However, Microsoft has not taken this easy way out, and instead, cached documents may indeed be edited.

Offline changes made to a file are preserved and synchronized. In the case of conflict during synchronization, the user is notified and asked to deal with the conflict.

---

Top