3.1 Example 1: Reading a File Using SMB 2.1or 3.x as Metadata Channel in Distributed Cache Mode (Cached Content Available)

This example includes the following use cases: Configuring SMB 2.1 or 3.x Content Server Caching (section 2.5.4.1.1), Configuring Content Client Caching Mode (section 2.5.4.1.3), Using SMB 2.1 or 3.x Metadata Retrieval (section 2.5.4.3.1), and Content Discovery and Retrieval (section 2.5.4.4.4).

The SMB 2.1 or 3.x protocol plays two distinct roles. The first role is to act as a member of the File Access system by providing the usual file-sharing resources between machines. The second role is to act as a transport for metadata from a content server to a content client, which enables the content client to participate in Content Caching and Retrieval.

The initial stages of the read operation from an SMB 2.1 or 3.x protocol operation perspective are the same, regardless of the caching mode (hosted cache, distributed cache, or none). After hashes have been identified as available (SMB 2.1 or 3.x is required for this), the retrieval mechanism varies depending on the mode of caching in effect. The caching mode is configurable, either manually or through the use of Group Policy. The following description contains an SMB 2.1 or 3.x stage and then a specific stage for distributed cache mode.

In the basic scenario, two peers, a content client (Peer1) and a peer role server (Peer2) within a LAN obtain content by reading, in turn, a file from a content server that is reached over a network link with a latency value greater than the value of the ADM element Network Latency. When the first peer (peer role server) reads the file, no cached content is available within the LAN, and therefore the file has to be retrieved by using an SMB 2.1 or 3.x read operation, as described in [MS-FASOD] and [MS-SMB2]. The Content Caching and Retrieval protocols do not change the requirements for authentication and access.

After at least 32 MB (1 MB equals one whole segment) of content has been retrieved for the first time and is available on the LAN, the content can potentially be cached and made available to other peers on the LAN.

Initial System State and Prerequisites

  • Content Caching and Retrieval is enabled on the content server as described in the Configuring SMB 2.1 or 3.x Content Server Caching (section 2.5.4.1.1) use case.

  • The mode of the content caching as distributed cache is configured on the content client (Peer1) and peer role server (Peer2) as described in the Configuring Content Client Caching Mode (section 2.5.4.1.3) use case.

  • The requested content is not available on the local cache of the content client (Peer1).

  • The cached content is available on the peer role server (Peer2) for the requested content of the content client (Peer1).

Message Sequence

This example begins with the normal sequence of events that would occur when a file is read by using the SMB 2.1 or 3.x protocol. For the specification for the SMB 2.1 or 3.x protocol, see [MS-SMB2], and for a description of that protocol's interaction with other protocols, see [MS-FASOD]. For details about opening a file by using SMB 2.1 or 3.x, see [MS-FASOD] and [MS-SMB2].

The initial sequence of a file read is an open operation that is followed by a SESSION_SETUP and TREE_CONNECT. An SMB 2.1 or 3.x TREE_CONNECT operation is required to access any share on an SMB 2.1 or 3.x server. The activities up to this point are independent of Content Caching and Retrieval; therefore, they are not described in this example.

SMB 2.1 or 3.x read file stages and distributed mode discovery and retrieval

Figure 10: SMB 2.1 or 3.x read file stages and distributed mode discovery and retrieval

  1. The content client (Peer1) sends an SMB 2.1 or 3.x TREE_CONNECT request to access the requested share on the content server.

  2. The content server responds with an SMB 2.1 or 3.x TREE_CONNECT response with the ShareFlags field set to SHI1005_FLAGS_ENABLE_HASH 0x00002000, as described in [MS-SMB2] section 2.2.10. This ShareFlags field value indicates that the share supports hash generation for content cache retrieval of data, that caching is enabled on the server share, and that the server can respond to requests for metadata if to the service being installed and configured. The flag informs the content client that it can make requests for metadata but does not guarantee that the metadata will be available.

  3. The content client attempts to obtain a lease that allows it to cache the content of read and write operations (see [MS-SMB2] section 3.2.4.3.8). The lease is requested as part of the CREATE operation by sending an SMB2_CREATE_REQUEST_LEASE request with a RequestedOplockLevel field value of SMB2_OPLOCK_LEVEL_LEASE.

  4. The server replies with a SMB 2.1 or 3.x CREATE response with a LeaseState field that has the requested SMB2_CREATE_RESPONSE_LEASE value, and a lease is obtained as part of the SMB 2.1 or 3.x CREATE request.

  5. The SMB 2.1 or 3.x content client performs a SRV_READ_HASH request (see [MS-SMB2] section 2.2.31.2) on the file with the CtlCode field set to FSCTL_SRV_READ_HASH to obtain the hash (metadata) for the target file.

  6. The content server sends an SMB2 IOCTL response with a SRV_READ_HASH response. If the hash is out-of-date, an error is returned to the client; if no hash exists for the specified file, an error is returned to the client.<18> A server can choose to update the hash for either of these situations. This example covers the case where no error is returned.

  7. After successfully obtaining a file hash, the client calculates the segment identifiers (HoHoDk) (see [MS-PCCRC] section 2.2) for the required content. The content client performs a multicast broadcast Probe message (see [MS-PCCRD] section 2.2.1) for the required content. The broadcast is targeted at any peers that listen on the local subnet.

  8. Peers that have the required content respond with a unicast ProbeMatch message, as described in [MS-PCCRD] section 2.2.2.2. In this example, because the peer role server (Peer2) has the required content, it responds with ProbeMatch message. The ProbeMatch message includes segment identifiers and the address of the peer that holds the content. The content client (Peer1) verifies that the response was sent by a peer on the local subnet and checks the HoHoDk segment identifiers to verify that at least one is associated with a Probe message on the Outstanding Probe List, as described in [MS-PCCRD].

  9. If the content client (Peer1) performs a simple download, it proceeds directly to step 11. Otherwise, it retrieves data by initiating the transport with the peer by sending an HTTP POST request to the root path of {/116B50EB-ECE2-41ac-8429-9F9E963361B7/} of the peer with the data, as described in [MS-PCCRR]. The initial HTTP POST request carries a REQUEST-MESSAGE (MSG_GETBLKLIST), as described in [MS-PCCRR] section 2.2.4.2, that is carried as an entity body of the HTTP POST request. This is a request for a download of a block list.

  10. The peer responds with an HTTP status code of 200 (OK) for the URL /116B50EB-ECE2-41ac-8429-9F9E963361B7/ as described in [MS-PCCRR]). The response carries a RESPONSE-MESSAGE (MSG_BLKLIST), as described in [MS-PCCRR] section 2.2.5.2, that indicates the blocks that are currently available for download from the peer.

  11. The content client then sends a number of REQUEST-MESSAGE (MSG_GETBLKS) as described in [MS-PCCRR] section 2.2.4.3, to the peer role server (Peer2) to retrieve all the required data, as described in [MS-PCCRR].

  12. The peer role server (Peer2) responds with RESPONSE-MESSAGE(MSG_BLK) as described in [MS-PCCRR] section 2.2.5.3. Steps 11 and 12 are repeated until all the required blocks within the identified segment have been retrieved. If multiple segments are required, multiple segment-retrieval sessions can be initiated (steps 9-12) with one or more peer role servers.

Final System State

  • The content client (Peer1) has acquired the required content.

  • The local cache of the content client (Peer1) has been updated with the required content.