Communication Components

Microsoft® SQL Server™ supports several methods of communicating between client applications and the server. When the application is on the same computer as SQL Server, 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:

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 TCP/IP Sockets API, can be used with only one protocol.

The following components manage communications between SQL Server and its clients in this sequence:

  1. The client application calls the OLE DB, ODBC, DB-Library, or Embedded SQL API. This causes the OLE DB provider, ODBC driver, or DB-Library DLL to be used for SQL Server communications.
  2. The OLE DB provider, ODBC driver, or DB-Library DLL calls a client Net-Library. The client Net-Library calls an IPC API.
  3. The client calls to the IPC API are transmitted to a server Net-Library by the underlying IPC. If it is a local IPC, calls are transmitted using a Windows operating IPC such as shared memory or local named pipes. If it is a network IPC, the network protocol stack on the client uses the network to communicate with the network protocol stack on the server.
  4. The server Net-Library passes the requests coming from the client to the SQL Server.

Replies from SQL Server to the client follow the reverse sequence.

This is an illustration of the communication path when the SQL Server application runs on a separate computer from the SQL Server installation. While the illustration shows the OLE DB Provider for SQL Server, SQL Server ODBC driver, and DB-Library DLL using specific Net-Libraries, there is nothing that limits these components to these Net-Libraries. The provider, driver, and DB-Library can each use any of the SQL Server Net-Libraries.

This is an illustration of the communication path when the SQL Server application runs on the same Microsoft Windows® 95/98 computer as SQL Server.

If SQL Server is running on a Microsoft Windows NT® computer, the Named Pipes Net-Library is used for local communications. For local connections with no network card, Windows NT uses the file subsystem to implement a named pipe connection.

There is a matched pair of client and server Net-Libraries for each IPC API supported by SQL Server.



Net-Library


IPC API used

Win32 client Net-Library

Server Net-Library
Protocols supporting the IPC API
Shared Memory Win32 Shared Memory DBmsshrn.dll
(Windows 95/98 only)
Ssmssh70.dll
(Windows 95/98 only)
Memory to memory copy (Local connections only)
Multiprotocol Windows RPC Dbmsrpcn.dll Ssmsrp70.dll File system (local)
TCP/IP
NetBEUI
NWLink
Named Pipes Windows Named Pipes Dbnmpntw.dll Ssnmpn70.dll
(Windows NT only)
File system (local)
TCP/IP
NetBEUI
NWLink
TCP/IP Sockets Windows Sockets Dbmssocn.dll Ssmsso70.dll TCP/IP
Novell IPX/SPX Netware IPX/SPX Dbmsspxn.dll Ssmssp70.dll NWLink
AppleTalk AppleTalk ADSP Dbmsadsn.dll
(Windows NT only)
Ssmsad70.dll
(Windows NT only)
AppleTalk
Banyan VINES Banyan VINES SPP Dbmsvinn.dll Ssmsvi70.dll
(Windows NT only)
Banyan VINES

SQL Server on Windows 95/98 does not support the server Named Pipes and Banyan Vines Net-Libraries because the operating system does not support the server part of the protocol API. SQL Server does support the client side of these Net-Libraries on Windows 95/98, so Windows 95/98 clients can use them to connect to SQL Server installations on Windows NT.

The Shared Memory Net-Library does not run on Windows NT computers and the AppleTalk Net-Library does not run on Windows 95/98 computers.

Some of the Net-Libraries support only one type of protocol stack. For example, the TCP/IP Sockets Net-Library requires a TCP/IP protocol stack and the SPX Net-Library requires an IPX/SPX protocol stack. The Named Pipes and Multiprotocol Net-Libraries support several protocol stacks.

The Microsoft SQL Server Net-Libraries have been tested intensively with the Microsoft protocol stacks and are supported with these stacks. Protocol stacks from other vendors should work, provided that the stacks fully support the APIs used by the Microsoft SQL Server Net-Libraries.

When the Named Pipes or Multiprotocol Net-Libraries are used to connect a client to a server on the same computer, and the computer does not have a protocol stack, the IPC APIs are implemented by the file system.

SQL Server can be listening on any combination of the server Net-Libraries at one time. These are installed during the server portion of SQL Server Setup and the person running the Setup program can choose which combination of Net-Libraries is installed. Here are the default server Net-Libraries installed by SQL Server Setup.

Windows NT Windows 95/98
TCP/IP Sockets TCP/IP Sockets
Multiprotocol Multiprotocol
Named Pipes Shared Memory

Each SQL Server automatically listens on all of the server Net-Libraries installed on the server.

All of the client Net-Libraries are installed with the utilities portion of the Setup program. On the client, you define what Net-Libraries are used to connect to particular servers using the SQL Server Client Network Utility. You can:

For a client to connect to a server running SQL Server, the client must use a client Net-Library that matches one of the server Net-Libraries the server is currently listening on. Also, both the client and server must be running a protocol stack supporting the network API called by the Net-Library being used for the connection. For example, if the client tries using the client Multiprotocol Net-Library, and the server is listening on the server Multiprotocol Net-Library, but the server is running with the TCP/IP protocol while the client computer is running only with the IPX/SPX protocol stack, the client cannot connect to the server. Both the client and the server must be using the same Net-Library and running the same protocol stack.

Each SQL Server client setup installs all of the client Net-Libraries. Setup sets Named Pipes as the default client Net-Library on both Windows NT and Windows 95/98. Because SQL Servers running on Windows NT listen to the Named Pipes Net-Library by default, all clients can use the default settings to connect to any Windows NT SQL Server installation running with the default settings. The server Named Pipes Net-Library is not supported by SQL Server installations running on Windows 95/98. Any client needing to connect to a server running on Windows 95/98 must use the SQL Server Client Network Utility to either change their default Net-Library or define server aliases specifying a Net-Library on which the Windows 95 server is listening.

When running an application on the same computer as SQL Server, you can use these names to reference the SQL Server installation.

Windows NT Windows 95/98
Computer name Computer name
(local)* (local)
.*  
*Where “(local)” is the word local in parentheses and “.” is a period, or dot.

Using the computer name is recommended. These connections will be made with the Named Pipes Net-Library running through the file system on Windows NT and the Shared Memory Net-Library on Windows 95/98. DB-Library does not support using (local).

SQL Server uses an application-level protocol called Tabular Data Stream (TDS) for communication between client applications and SQL Server. The TDS packets are encapsulated in the packets built for the protocol stack used by the Net-Libraries. For example, if you are using the TCP/IP Sockets Net-Library, then the TDS packets are encapsulated in the TCP/IP packets of the underlying protocol.

You can configure the SQL Server packet size, which is the size of the TDS packets. The size of the TDS packets defaults to 4 KB on most clients (DB-Library applications default to 512 bytes), which testing has shown to be the optimal TDS packet size in almost all scenarios. The size of the TDS packets can be larger than the size of the packets in the underlying protocol. If this is the case, the protocol stack on the sending computer disassembles the TDS packets automatically into units that fit into the protocol packets, and the protocol stack on the client computer reassembles the TDS packets on the receiving computer.

See Also
Managing Servers Managing Clients

  


(c) 1988-98 Microsoft Corporation. All Rights Reserved.