Microsoft® SQL Server™ 2000 supports several methods of communicating between client applications and the server. When the application is on the same computer as an instance of SQL Server 2000, Windows Interprocess Communication (IPC) components, such as local named pipes or shared memory, are used. When the application is on a separate client, a network IPC is used to communicate with SQL Server.
An IPC has two components:
The API is a definition of the set of functions software uses to send requests to and retrieve results from the IPC.
The protocol defines the format of the information sent between any two components communicating through the IPC. In the case of a network IPC, the protocol defines the format of the packets sent between two computers using the IPC.
Some network APIs can be used over multiple protocols. For example, the Named Pipes API and the Microsoft Win32® RPC API can both be used with several protocols. Other network APIs, such as the Banyan VINES API, can be used with only one protocol.
The SQL Server 2000 client communication components require little or no administration when they connect to SQL Server 2000. Although the actual implementation of the communication components is more complex than in earlier versions of SQL Server, SQL Server 2000 users are shielded from this when connecting to instances of SQL Server 2000. The SQL Server 2000 client software dynamically determines the network address needed to communicate with any instance of SQL Server 2000. All the client software needs is the network name of the computer on which the SQL Server 2000 instance is running, and the name of the instance if connecting to a named instance. There are very few reasons for SQL Server 2000 users to manage the client communications components using the Client Network Utility.
SQL Server 2000 Enterprise Edition introduces support for System Area Network (SAN) protocols built using the Virtual Interface Architecture (VIA). A SAN is a high-speed, highly reliable network for interconnecting servers or clusters of servers. A multi-tier, distributed system can generate extremely high levels of network traffic between servers. Gaining high performance in such a system is possible only if message transmissions are fast enough to minimize the time the servers spend processing messages and waiting for replies. Compared to local area networks (LANs) or wide area networks (WANs), SANs support high levels of messaging traffic by lowering CPU loads and message latency. SANs are also more reliable than LANs or WANs, and are implemented in groups or clusters of servers that are located close together, such as in the same computer room.
Compaq®, Intel®, Microsoft, and other companies have defined Virtual Interface Architecture (VIA) as a generic definition of a SAN that allows many possible hardware implementations. The Virtual Interface Architecture allows a VIA provider to implement a flexible, scalable, robust messaging component built at low cost using standard components. VIA SANs can support the intense messaging requirements of large Web servers.
The Virtual Interface Architecture defines both an API and a protocol. The API is referred to as the VIA API, and protocol is referred to as the VIA protocol.
SANs are well suited for these uses with SQL Server 2000:
SQL Server 2000 supports the Giganet VIA SAN implementation. Because SANs are intended to support the high communications bandwidth between servers, SQL Server 2000 only supports the VIA Net-Libraries on the Windows NT® Server, Windows 2000 Data Center, Advanced Server, and Server operating systems.