The Net-Library (often called Net-Lib, but in this book I'll use Net-Library) abstraction layer enables SQL Server to read from and write to many different network protocols, and each such protocol (such as TCP/IP sockets) can have a specific driver. The Net-Library layer makes it relatively easy to support many different network protocols without having to change the core server code.
A Net-Library is basically a driver that's specific to a particular network interprocess communication (IPC) mechanism. (Be careful not to confuse driver with device driver.) All code in SQL Server, including Net-Library code, makes calls only to the Microsoft Win32 subsystem. SQL Server uses a common internal interface between Microsoft Open Data Services (ODS)—which manages its use of the network—and each Net-Library. If your development project needs to support a new and different network protocol, you can handle all network-specific issues by simply writing a new Net-Library. In addition, you can load multiple Net-Libraries simultaneously, one for each network IPC mechanism in use.
SQL Server uses the Net-Library abstraction layer on both the server and client machines, making it possible to support several clients simultaneously on different networks. Microsoft Windows NT/2000 and Windows 98 support the simultaneous use of multiple protocol stacks. Net-Libraries are paired. For example, if a client application is using a Named Pipes Net-Library, SQL Server must also be listening on a Named Pipes Net-Library. The client
application determines which Net-Library is actually used for the communication, and you can control the client application's choice by using a tool called the Client Network Utility. You can easily configure SQL Server to listen on multiple Net-Libraries by using the Server Network Utility, which is available under Programs\Microsoft SQL Server on the Start menu.
SQL Server 2000 has two primary Net-Libraries: Super Socket and Shared Memory. TCP/IP, Named Pipes, IPX/SPX, and so on are referred to as secondary Net-Libraries. The OLE DB Provider for SQL Server, SQL Server ODBC driver, DB-Library, and the database engine communicate directly with these two primary network libraries. Intercomputer connections communicate through the Super Socket Net-Library. Local connections between an application and a SQL Server instance on the same computer use the Shared Memory Net-Library if Shared Memory support has been enabled (which it is, by default). SQL Server 2000 supports the Shared Memory Net-Library on all Windows platforms.
Figure 3-1. The major components of the SQL Server architecture.
The Super Socket Net-Library has two components:
Communication path If the client is configured to communicate over TCP/IP Sockets or NWLink
IPX/SPX connection, the Super Socket Net-Library directly calls the Windows Socket 2 API for the communication between the application and the SQL Server instance.
If the client is configured to communicate over a Named Pipes, Multiprotocol, AppleTalk, or Banyan VINES connection, a subcomponent of the Super Socket Net-Library called the Net-Library router loads the
secondary Net-Library for the chosen protocol and routes all Net-Library calls to it.
Encryption layer The encryption is implemented using the Secure Sockets Layer (SSL) API. The level of
encryption, 40-bit or 128-bit, depends on the Windows version on the application and SQL Server-based computers. Enabling encryption can slow network performance not only because of the extra work of encrypting and decrypting communication between the client and the server but also because an extra roundtrip is required between the client and the server every time a connection is made.
Shared Memory Net-Library communication is inherently secure without the need for encryption. The Shared Memory Net-Library never participates in intercomputer communication. The area of memory shared
between the application process and the database engine process cannot be accessed from any other Windows process.
For compatibility with earlier versions of SQL Server, the Multiprotocol Net-Library continues to support its own encryption. This encryption is specified independently of the SSL encryption and is implemented by calling the Windows RPC encryption API.
Figure 3-2 (taken from SQL Server Books Online) shows SQL Server 2000's Net-Library architecture.
The distinction between the IPC mechanisms and the underlying network protocols is important. IPC mechanisms used by SQL Server include Named Pipes, RPC, SPX, and Windows Sockets. Network protocols used include TCP/IP, NetBEUI, Shared Memory, NWLink IPX/SPX, Banyan VINES SPP, and AppleTalk ADSP. Two Net-Libraries, Multiprotocol and Named Pipes, can be used simultaneously over multiple network protocols
(NetBEUI, NWLink IPX/SPX, and TCP/IP). You can have multiple network protocols in your environment and still use only one Net-Library.
SQL Server 2000 running on Windows NT/2000 supports impersonation of security contexts to provide an integrated logon authentication capability called Windows Authentication. Windows Authentication operates over
network protocols that support authenticated connections between clients and servers. Such connections are referred to as trusted connections and are supported by SQL Server 2000 using any available Net-Library. Instead of requiring a separate user ID/password logon each time a connection to SQL Server is requested, SQL Server can impersonate the security context of the user running the application that requests the connection. If that user has sufficient privileges (or is part of a Windows NT/2000 domain group that does), the connection is established. Note that Windows Authentication is not available when SQL Server is running on Windows 98. When you connect to SQL Server running on Windows 98, you must specify a SQL Server logon ID and password.
Figure 3-2. SQL Server 2000's Net-Library Architecture. Which Net-Library Is Fastest?
Strictly speaking, the TCP/IP Sockets Net-Library is the fastest Net-Library. In a pure network test that does nothing except throw packets back and forth between Net-Library pairs, the TCP/IP Sockets Net-Library is perhaps 30 percent faster than the slowest Net-Library. But in LAN environments and applications, the speed of the
Net-Library probably makes little difference because the network interface is generally not a limiting factor in a well-designed application.
On a LAN, however, turning on encryption does cause a performance hit. But again, most applications probably wouldn't notice the difference. Your best bet is to choose the Net-Library that matches your network protocols and provides the services you need in terms of unified logon, encryption, and dynamic name resolution. (I'll explain these choices further in Chapter 4.)