3.1.1 Abstract Data Model
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The organization is provided to facilitate the explanation of how the protocol behaves. This specification does not mandate that implementations adhere to this model as long as their external behaviors are consistent with that described in this specification.
This data model requires elements to be synchronized with the Common Internet File System (CIFS) Protocol, the Server Message Block (SMB) Protocol, or the Server Message Block (SMB) Version 2 Protocol servers. This data model also requires that these protocols maintain these elements coherently with this data model at all times. An implementation that uses this data model has to observe atomicity requirements in order that all these protocols always share and maintain an identical view of the common data.
A server implementing this RPC interface contains several logical elements: an SMB file server, one or more network protocol transports, and a list of shared resources that the server is making available. There could also be virtual shares and services that provide SMB file server referrals for these virtual shares.<32>
One or more network protocol transports SHOULD be configured by a server implementing this RPC interface, to be associated with an SMB file server at its initialization.<33>A transport is a protocol that logically lies below the file server and provides reliable delivery of file server messages. If a transport is associated with a file server, it is said to be bound to or enabled for the server. The act of associating a transport with the file server is referred to as binding. The binding between a file server and a transport is represented by a "transport handle".
Transports can be dynamically bound (or enabled) and unbound (or disabled) from a file server. The server opens a transport handle when a transport is bound and closes it upon unbind. A transport MUST be bound to the file server for the server to receive messages through the transport. A transport has an implementation-specific name; transport names are unique on a per-computer basis.<34>
When a transport is bound to a file server, the server MUST perform the transport binding, as specified in [MS-SMB] section 2.1, for the requested transport.
The file server can make available multiple sets of resources (that is, files, printers, pipes, disks, and mailslots) for access by Common Internet File System (CIFS) clients over the network. Each set is referred to as a share and is identified by a unique network name. Shares can be made dynamically available, and the act of making a share available is referred to as adding a share. Shares can also be made unavailable dynamically, which is referred to as removing a share. The server MUST keep a list of all active shares that are identified by a share identifier. If the share is marked as a sticky share, the same information MUST be stored in persistent storage. The server MUST support two-phase deletion of shares.<35>
The SMB server assigns all objects (active sessions, connections, opened resources, shares, and transports) unique identifiers. Identifiers are integer values that allow the server to uniquely identify the corresponding object. The server generates these identifiers when the corresponding object is created. The client obtains these identifiers in response to one of its requests (for example, an SMB client gets the session identifier in response to a Session Setup request) and then uses these identifiers in future requests to refer to the corresponding object. To support enumerating these objects, the server MUST store each of these objects in separate lists.
The server MUST keep track of several implementation-dependent statistics (as described by the STAT_SERVER_0 (section 2.2.4.39) structure) about the server performance that clients can query by calling the NetrServerStatisticsGet method.
If the server supports DFS, as specified in [MS-DFSC], it MUST provide a software component called a DFS driver that processes all messages pertaining to DFS. These messages are specified in section NetrDfsGetVersion (Opnum 43) (section 3.1.4.35) through section NetrDfsManagerReportSiteInfo (Opnum 52) (section 3.1.4.43). The server MUST keep a list of the DFS shares and links and the associated information about the shares and links.