Implementation
Client-server approach
SMB works through a peer-to-peer approach, where a client makes specific requests and the server responds accordingly. One section of the SMB protocol specifically deals with access to filesystems, such that clients may make requests to a file server; but some other sections of the SMB protocol specialise in inter-process communication (IPC). Developers have optimized the SMB protocol for local subnet usage, but users have also put SMB to work to access different subnets across the Internet — exploits involving file-sharing or print-sharing in MS Windows environments usually focus on such usage.
SMB servers make their file systems and other resources available to clients on the network. Client computers may want access to the shared file systems and printers on the server, and in this primary functionality SMB has become best-known and most heavily used. However, the SMB file-server aspect would count for little without the NT domains suite of protocols, which provide NT-style domain-based authentication at the very least. The NT Domains protocols offer MSRPC services available almost exclusively on SMB IPC "named pipe", and almost all implementations of SMB servers use NT Domain authentication to validate user-access to resources.
Performance issues
Many people believe that the SMB protocol makes heavy use of network bandwidth because each client broadcasts its presence to the whole subnet. SMB itself does not use broadcasts. The broadcast problems commonly associated with SMB actually originate with the NetBIOS service location protocol. By default, a Microsoft Windows server will use NetBIOS to advertise and locate services. NetBIOS functions by broadcasting services available on a particular host at regular intervals. While this usually makes for an acceptable default in a network with fewer than 20 hosts, broadcast traffic will cause problems as the number of hosts increases. A proper implementation of a NetBIOS Name Server (NBNS) can mitigate this problem — for example Windows Internet Naming Service (WINS) offers a suitable solution in Microsoft environments. WINS uses a much more advanced system of registration and centralized service requests, but imposes its own complexity upon the design and maintenance of the network. Microsoft recommends the use of Dynamic DNS, another viable option, in Microsoft Active Directory environments.
Network designers should expect that latency will have a significant impact on the performance of the SMB protocol. Monitoring reveals this most commonly in cases of navigating among directories through SMB when significant network latency exists between hosts. For example, a VPN connection over the Internet will often introduce network latency, which can make for a frustrating experience.
Microsoft's modifications
Microsoft added several extensions to its own SMB implementation. For example, it added NTLM Version 2 because NTLM version 1 (derived from the original legacy SMB specification's requirement to use IBM "LanManager" passwords) uses DES in a flawed manner. Additionally, the NT 4.0 Domain Logon protocols use 40-bit encryption outside of the United States of America, which does not conform with modern security standards.
SMB2
Microsoft introduced a new version of the Server Message Block (SMB) protocol ( SMB 2.0 or SMB2) with Windows Vista in 2006.
SMB2 improves prior versions of SMB for Windows by adding the ability to compound multiple actions into a single request, which significantly reduces the number of round-trips the client needs to make to the server, improving performance as a result. SMB1 also has a compounding mechanism — known as AndX — to compound multiple actions, but Microsoft clients rarely use AndX.
SMB2 supports larger buffer-sizes, which can provide better performance with large file-transfers.
SMB2 introduces the notion of "durable file handles": these allow a connection to an SMB server to survive brief network-outages, such as may occur in a wireless network, without having to construct a new session.
SMB2 includes support for symbolic links.
The SMB 1 protocol often uses 16-bit sizes. SMB2 uses 32 or 64 bits for many of these, and 16 bytes in the case of file-handles.
Windows Vista uses SMB 2.0 when communicating with other Windows Vista machines, or with Windows Server 2008. SMB 1.0 continues in use for connections to any previous version of Windows, or to Samba. Samba 4 also includes experimental support for SMB 2.0.
SMB2 brings two substantial benefits to Microsoft:
1. clearer intellectual-property ownership. SMB 1, originally designed by IBM, became part of a wide variety of non-Windows operating systems such as SCO Xenix, OS/2 and DEC VMS (Pathworks). X/Open standardised it partially; it also had draft IETF standards which lapsed. (See http://ubiqx.org/cifs/Intro.html for historical detail).
2. a relatively clean break with the past. Microsoft's SMB1 code has to work with a huge variety of SMB clients and servers. A large number of items in the protocol remain optional (such as short and long filenames). SMB1 features many levels of information for commands (selecting what structure to return for a particular request). SMB1 added Unicode at a later date. SMB2 involves significantly reduced compatibility-testing for Microsoft (currently involving only other Windows Vista clients and servers). SMB2 code has considerably less complexity since far less variability exists (for example, non-Unicode code paths become redundant as SMB2 requires Unicode support).