6.4 File Access Services Protocols
File access services enable applications to discover, access, and share files that are hosted on or made available by a file server, using a network between them, in a secure and managed environment. File access services also enable file servers to manage and replicate files in a distributed environment
Most businesses and many personal computing environments have a requirement for file hierarchies stored in a file system (object store) on one computer to be accessed and manipulated by applications on other computers. This scenario is typically referred to as file sharing or remote file access. A key goal is to ensure application compatibility by providing broadly the same semantics to clients as if the shared object store were local to them. This compatibility would not be provided by sharing the files through a protocol with more limited semantics, such as FTP or HTTP. The file access protocols address the need for ensured compatibility.
The File Access Services Protocols Overview [MS-FASOD] fully describes these protocols. The File Access Services protocols are listed in [MS-FASOD] section 2.2.
Remote file systems enable an application that runs on a local computer to access files stored on a remote computer. See [Rifkin1986] for a discussion on providing transparent access to remote files.
Support for remote file systems in Windows is based on installable drivers and therefore can be extended. The support of remote file systems requires three components:
Software installed on the client to use a transport protocol.
A transport protocol used for communication and a network connection.
Software installed on the server to use a transport protocol.
The software component of a remote file system on a client computer is referred to in Windows as a network redirector because it is responsible for redirecting requests for file operations from local client applications to a remote server where the requests are processed. The network redirector receives responses from the remote server that are then returned to the local application. The local application might be unaware that remote file I/O rather than local file I/O has occurred. Hence the network redirector software creates the appearance on the client system that remote files and resources are the same as local files and resources and allows them to be used and manipulated in the same way. In Windows, it is possible to have multiple redirectors installed at any given time. The Windows Driver Kit (WDK) [MSDN-WinDriverKit] gives details for developing providers, which are essentially device drivers.
Figure 1: The Windows file provider architecture
Note Information about the local object store in Windows can be found in [FSBO].
The Multiple UNC Provider component of Windows is a Universal Naming Convention (UNC) resource locator responsible for determining the correct provider for UNC connections. By using the Multiple UNC Provider to find the provider for a UNC connection, Windows can simultaneously have multiple network redirectors installed that support various formats of UNC names.
With multiple redirectors that support UNC names, there is the potential that more than one provider could service a UNC name. Therefore, an arbitrator is needed. Windows inspects an application's UNC requests, determines which of the currently installed providers, if any, can service the UNC name, and routes the application request to that provider.
Provider selection is invoked as part of all UNC name-based I/O requests. When Windows receives a UNC request, it accesses all of the installed providers in order to determine which provider, or providers, can accept the request. Further details on the process are available in [WININTERNALS] section 13.
After the initial routing is determined, no further interaction from provider selection is required and the application accesses the file via the provider as it would any file-based service, whether local or remote.
CIFS is a dialect of the SMB network file sharing protocol, designed to provide concurrent access to directories and files hosted on servers. CIFS is applicable for all scenarios that involve transferring files between client and server. It is also applicable for accessing centralized print queues, and for interprocess communications using named pipes.
The Server Message Block (SMB) Protocol specified in [MS-SMB] lists extensions, enhancements, and clarifications to the CIFS protocol. In contrast, the Server Message Block (SMB) Protocol Versions 2 and 3 specified in [MS-SMB2] is an entirely new file sharing protocol based on SMB concepts. Server Message Block Protocol Versions 2 and 3 are referred to as the SMB 2 Protocol.
SMB and SMB 2 serve a special role in Windows protocols because they offer a construct known as the named pipe. The name of the pipe serves as the endpoint for the communication in the same manner as a port number serves as the endpoint for TCP sessions.
Network captures of SMB 2 protocol traffic can include input/output control (IOCTL) codes relating to device-specific behavior, such as failover clustering, that are not part of the SMB 2 Protocol. For more information on these IOCTLs, which are defined in the Windows SDK header file, winioctl.h, see [MSDN-DevInOutCtrl].