SMB 2.x and Interlocking Technologies

SMB, Connecting Protocols, and BranchCache

So we’ve been discussing SMB (Server Message Block) 2.x and its various benefits, but so far we haven’t talked about how the new file-sharing protocol works together with other bits and pieces in Server 2008 R2 and Windows 7. It might be worth pointing out some of these points of interoperability. (By the way, as a point of interest, you may also know SMB by its alter-ego, CIFS, which stands for Common Internet File System.) First off, SMB 2.1 (and 2.0 for that matter) are supported over two transport protocols, TCP and NetBIOS-over-TCP (NetBT). (Sorry, no SMB 2.x over NetBEUI. [grin]) Second, SMB 2.x is (as you’d expect) compatible with DFS (Distributed File System) and access to DFS shares is accomplished via SMB 2 messages. SMB 2 also works with both Kerberos and NTLM authentication protocols. When we start looking specifically at SMB 2.1, it turns out that it is a big enabler of BranchCache, the extension of the file caching concept to branch offices that have to reach across WAN links to open centrally-stored content. (The formal name for BranchCache, by the way, is “Windows Content Caching and Retrieval System,” sometimes referred to as WCCRS.) In BranchCache, clients can compare hashes of content blocks to see if they might be stored locally on a Windows 7 or Server 2008 R2 system at the branch office. SMB 2.1 supports the ability of a file server to provide an encrypted hash list (metadata) to the clients. Without this capability in SMB 2.1, the whole BranchCache concept would have had to be engineered quite differently, at least from the file server side. (The other protocol BranchCache works with is HTTP.) SMB 2.1 also provides a mechanism for clients to discover whether a specific share is configured to permit caching.

Copyright © 2010 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022