Microsoft SQL Server Net-Library architecture for client-server applications is based on the Net-Library concept that abstracts the client and server applications from the underlying network protocols being used. Figure 8.2 shows how SQL Server and related products can be accessed from practically any network environment.
Figure 8.2 Net-Library Architecture
The Net-Library architecture provides a method of sending TDS (used by Microsoft SQL Server, Open Data Services, and SYBASE) via an IPC across a physical network connection. The Net-Library architecture also provides a transparent interface to the DB-Library APIs and the SQL Server driver for ODBC.
Net-Libraries are linked dynamically at run time. With the Microsoft Windows NT, Windows, and OS/2 operating systems, Net-Libraries are implemented as DLLs, and multiple Net-Libraries can be loaded simultaneously. With MS-DOS, Net-Libraries are implemented as terminate-and-stay-resident (TSR) programs, and only one can be loaded at a time.
The Net-Library architecture can be divided into two components—server-side Net-Libraries and client-side Net-Libraries.
Microsoft SQL Server uses the server-side Net-Library architecture that was first introduced with Microsoft SQL Bridge. It can accept client requests across multiple network protocols at the same time.
Figure 8.3 illustrates the integration of server-side Net-Libraries with the various SQL Server–based products on the Windows NT platform.
Figure 8.3 Server-Side Net-Library Architecture on the Windows NT Platform
The default Net-Library is named pipes.
When a server-side Net-Library is loaded by an application such as SQL Server, the Net-Library implements a network-specific way of establishing communication with clients and, in some cases, registers its presence on the network. SQL Server looks at the Windows NT Registry to determine which Net-Library to load on startup and which parameters to pass to it. The SQL Server Monitor process also uses a server-side Net-Library to communicate with clients and to search the following Registry key for network-specific parameters:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\ServerAt startup, SQL Server specifies a value for the server_name parameter in the SRV_CONFIG structure of Open Data Services. This value identifies which Registry key SQL Server will search for values of the ListenOn and connection_string Registry entries. (By default, SQL Server looks in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\Server.)
Each connection_string Registry value is read and passed on to the associated Net-Library (for example, named pipes) that is listed in the ListenOn field in the Server subkey. Each Net-Library acts upon the connection_string differently.
If there is no connection_string associated with the Net-Library, SQL Server does one of the following:
If the server_name subkey and the SQL#Server\Server subtree do not exist, or the Registry cannot be accessed, SQL Server assumes that the named pipes DLL (for the default Net-Library) is loaded, and no parameter is passed. (Named pipes access can be turned off by using the Registry Editor to explicitly delete the named pipes entry from the SQL#Server\Server subkey.)
Remote stored procedure calls and the Microsoft SQL Administrator tool also use the DB-Library/Net-Library architecture under Windows NT.
When a call is made to open a connection to SQL Server, the API involved (DB-Library or the SQL Server driver for ODBC) determines which client-side Net-Library should be loaded to communicate with SQL Server or Open Data Services. (This process is described in more detail later in this chapter.)
Figure 8.4 shows client-side Net-Libraries used to communicate with SQL Server on the server side.
Figure 8.4 Client-Side Net-Library Architecture