Multi-Protocol Clients

SQL Server 6.0 includes the new Multi-Protocol Net-Library, which takes advantage of the powerful remote procedure call (RPC) facility of Windows NT to provide new functionality and ease of use. Multi-Protocol Net-Library provides the ability to communicate simultaneously over one or more IPC mechanisms supported by Windows NT.

Note Only TCP/IP Windows Sockets, NWLink IPX/SPX, and Named Pipes are considered to be tested and supported.

For Multi-Protocol, the server's machine name is used by clients for name resolution.

To configure a Windows NT-based client to use the Multi-Protocol Net-Library

On the client, make sure you have support for at least one IPC protocol supported under Multi-Protocol on the server (Named Pipes, IPX/SPX, TCP/IP, or Windows sockets).
When using SPX/IPX via NWLink, you also need to install the Windows NT NetWare Client services.
From the Microsoft SQL Server 6.0 program group, choose the SQL Client Configuration icon, and then set Multi-Protocol as the default Net-Library.

Note The Win32 Multi-Protocol network library is supported on Windows NT versions 3.5 and 3.51. However, connections are not supported from Windows NT version 3.5 clients to Windows NT version 3.51 servers. Clients running Windows NT version 3.5 should upgrade to version 3.51 in order to connect via the Multi-Protocol Net-Library to servers running Windows NT version 3.51.

To configure a Windows-based client to use the Multi-Protocol Net-Library

On the client, make sure you have support for a protocol supported under Multi-Protocol on the server (Named Pipes, IPX/SPX or TCP/IP sockets).
Choose the SQL Client Configuration Utility from the SQL Server Tools program group, and then select Multi-Protocol as the default Net-Library.

Both Windows- and Windows NT-based clients can also create aliases for specific server names to use the Multi-Protocol Net-Library, by using the Advanced option in the SQL Client Configuration Utility.

To create an alias for a specific server name to use the Multi-Protocol Net-Library

From the SQL Client Configuration Utility, select the Advanced option.
In the Server box, enter the machine name of the system running SQL Server and listening on the Multi-Protocol Net-Library.
In the DLL Name box, select Multi-Protocol (for Windows NT-based clients) or enter DBMSRPC3 (for Windows-based clients).
The Connection String box may be left blank, since the server's machine name is used for name resolution. However, if the alias name being used is different, the machine name must be supplied as the connection string.

SECURITY.DLL and the Path on 16-bit Clients

When using the 16-bit Window Multi-Protocol Net-Library, the SECURITY.DLL is necessary for integrated security and encryption. The 16-bit Windows setup program copies this DLL to the SQL Server client directory. Note that since the 16-bit Windows setup program does not modify the path, this directory must be placed in the computer's path if you will be running SQL Server applications that do not reside in this directory.

Integrated Security and 16-bit Clients

The 16-bit Windows Multi-Protocol Net-Library (by default) assumes integrated security on connection attempts. Thus, to allow standard connections to SQL Server (non-integrated security when the server is started in mixed or standard mode), make the following change to the WIN.INI file to bypass the authentication dialog box:

[RPCnetlib]
Security=none

On Windows 3.1-based workstations using the 16-bit Windows Multi-Protocol Net-Library with SQL Server Integrated Security, the authentication dialog box allowing login to a Windows NT domain generally appears on the first connection attempt to the server from an application. However, some applications (such as ISQL\w) use "make/break" logic designed to minimize idle connections to the server, creating situations in which the authentication dialog box appears each time a connection is closed and then reopened.

Client-side Encryption for 16-bit Clients

To enforce encryption over the Multi-Protocol Net-Library on a per-client basis for a 16-bit Windows-based client, set the following value in the client's WIN.INI file:

[RPCnetlib]
Security=Encrypt

This will cause all communication over the Multi-Protocol Net-Library between this client and the server to be encrypted. (Only this client's communications will be encrypted. Other clients using the Multi-Protocol Net-Library, which do not have this parameter set, will not use encryption.)

Client-side Encryption for 32-bit Clients

For Windows NT- or Windows 95-based clients, to enforce encryption over the Multi-Protocol Net-Library on a per-client basis, you must create the RPCNetlib Registry key and the following Registry value:

HKEY_LOCAL_MACHINE
    \SOFTWARE
        \Microsoft
            \MSSQLServer
                \Client
                    \RPCNetlib

Value Name: Security
Data Type: REG_SZ
String: Encrypt

Server Enumeration

There is no support for server enumeration with the Multi-Protocol Net-Library. From applications that have options to list servers by calling dbserverenum, you will not be able to identify SQL Servers listening on the Multi-Protocol Net-Library.

Name Resolution

Due to the nature of the Multi-Protocol Net-Library architecture, no server-side listen-on service name needs to be provided when SQL Server is loading SSMSRPCN.DLL. By default, clients connect by simply using the machine name. When establishing a connection, the Net-Library passes the machine name to the RPC run time, which determines which IPC/protocols are available and attempts to use each one until a connection is established. (Only NWLink IPX/SPX, TCP/IP sockets, and Named Pipes are considered tested and supported.)

To accomplish the machine name to node connection, the RPC run time uses a naming service compatible with the transport used (WINS for TCP/IP, SAP for NWLink IPX/SPX and Net BIOS broadcasts for Named Pipes). No ports or sockets need to be specified in the connection string, since a local RPC database is used to resolve the names over the supported protocols. This all happens behind the scenes, so by default, only the machine name needs to be passed to establish a connection. This is the desired configuration and makes the general configuration of the client and server very easy.

However, for troubleshooting and testing, it is possible for specific connection strings to be used. A client can establish a connection using the Multi-Protocol Net-Library over a specific protocol only, and also (if desired) specify the hard-coded connection string. Based on this, the Net-Library will allow direct connection if a defined RPC name is passed on the connection attempt. For example, to establish a connection in which the client-side Multi-Protocol Net-Library will only attempt to use TCP/IP sockets, you could use either of the following formats for the connection string:

ncacn_ip_tcp:machine_name
ncacn_ip_tcp:11.125.9.53[3848]

In the first example, the connection will be established over TCP/IP sockets and the machine name will be used for the appropriate name resolution method. In the second example, the actual IP address and socket is used to identify SQL Server. Similarly, for NWLink IPX/SPX connections, you could use either of the following formats for the connection string:

ncacn_spx:machine_name
ncacn_spx:~00000023AF737F208AB[24584]

For Named Pipes connections, you could use the following format for the connection string:

ncacn_np:machine_name
ncacn_np:\\\\SERVER[\\pipe\\0000008D.001]

For all of these cases (TCP/IP sockets, NWLink IPX/SPX, or Named Pipes), you can determine what actual address the server-side Multi-Protocol Net-Library started listening on for each protocol by examining the Windows NT Application log messages which are written when SQL Server starts and the Net-Libraries are loaded.

Note When stopping and starting a SQL Server listening on this Net-Library, the actual address may vary, depending on available socket addresses for Named Pipes. Therefore, it is always preferable to use the machine name when establishing connections.