IPC Mechanisms

How named pipes, mailslots, and other mechanisms facilitate communication in your NT network

You've probably heard of named pipes, mailslots, and Windows Sockets (Winsocks), but do you know what they are and how Windows NT uses them? NT networks use these and other interprocess communications (IPC) mechanisms to establish communication channels in a distributed computing environment. But before you learn about how these mechanisms work, you need to understand how distributed computing fits in the client/server model.

The Distributed Computing Network
Most networks, including NT systems, use a client/server model in which the client computer makes a request and the server computer fulfills it. In a distributed computing network, both the client and the server perform tasks. But the workload isn't distributed evenly. Because the server is typically more powerful and faster than the client, the server handles most of the tasks, leaving the smaller ones for the client. Distributed computing is not limited to two machines. Several clients and servers in a network can perform tasks. And in an NT network, NT machines can assume the role of server or client.

Communication is key at all levels of a distributed computing network. At the machine level, clients and servers must communicate with each other. For example, when you run a distributed application (i.e., an application that splits processing between the client and server), the various clients and servers must communicate task-related information. At the operating system (OS) level, various OS components need to communicate with each other. For example, user-mode and kernel-mode components must communicate OS-related information. Communication is vital even at the application level. For example, threads in a process must communicate with each other and with threads from different processes.

IPC mechanisms are the conduit for communication at all levels, and the IPC Manager is responsible for calling these mechanisms into action. The IPC Manager runs in kernel mode, as Figure 1 shows, page 194. As a result, the IPC Manager runs at a high priority, has access to all system resources, and can see the address spaces of both client and server processes. When the client and server processes cannot call each other's functions directly, the IPC Manager calls on the services of an appropriate IPC mechanism. NT has seven primary IPC mechanisms: named pipes, mailslots, NetBIOS, Winsock, Network Dynamic Data Exchange (NetDDE), remote procedure calls (RPCs), and distributed component object model (DCOM).

Named Pipes
Named pipes provide a reliable, bidirectional communication channel to transfer data between a client and server. NT implements named pipes as file system drivers. Thus, they are available to all processes, including local processes on a machine and Remote Access Service (RAS) processes.

Named pipes offer connection-oriented messaging. This type of messaging is secure and efficient (i.e., there's no data loss) because it requires that the receiver acknowledge receipt of all data sent. Connection-oriented messaging is akin to making a telephone call. When you dial a number and someone answers the phone, a connection is made and you relay your message. When you hang up, the connection terminates. But if you dial a number and no one answers the phone, you don't relay your message because a connection was never made.

For added security, NT includes special APIs and the impersonation feature in named pipes messaging. Impersonation enhances the security of the server application. When an application that uses named pipes (e.g., SQL Server) receives a request from a client, the server will impersonate the client before honoring the request. Although the server might have the authority to perform the request, the client might not. If the client doesn't have the necessary authority, the server denies the client's request.

Various software products use named pipes, including NT and SQL Server. NT uses named pipes in the Win32 logon process.

Mailslots
Like named pipes, NT implements mailslots as file system drivers. Unlike named pipes, mailslots do not provide connection-oriented messaging.

Although first-class mailslots (used in LAN Manager) offer connection-oriented services, NT supports only second-class mailslots, which don't require an acknowledgment from the receiver. NT sends the message whether or not anybody is listening. Although mailslots are not connection-oriented, they are still reliable.

Many NT functions use mailslots. For example, NT uses mailslots for the Computer Browser service and to register computer names, workgroups, and domains on the network. Double-clicking Network Neighborhood, adding a new workstation, and sending a broadcast message to another computer or user on the LAN also uses mailslots.

NetBIOS
Network Basic I/O System (NetBIOS) is an API that IBM designed in the early 1980s. Just as its name implies, NetBIOS is basic. It includes several commands for connection-oriented functions.

IBM later extended NetBIOS into the NetBIOS Extended User Interface (NetBEUI) protocol. The most important difference between NetBIOS and NetBEUI is that NetBIOS is an API for developing client/server applications, and NetBEUI is a transport protocol that governs how NT sends information over the network.

Because the transport protocol is separate from the API, protocols other than NetBEUI can support NetBIOS. For example, Microsoft's TCP/IP and NWLink IPX/SPX protocols support NetBIOS. TCP/IP and IPX are routable; NetBEUI is not. Because of the NetBIOS layer on TCP/IP and IPX, you can eliminate NetBEUI and still have complete NetBIOS functionality on your network, including the ability to run NetBIOS applications on a routed network.

Microsoft has added extensions to NetBEUI; in NT, Microsoft calls the extended NetBEUI the NetBIOS Frame (NBF). By assigning session numbers on a per-remote-adapter basis, NBF removes NetBIOS' limitation of 254 sessions per node. With NBF, each process can communicate with 254 other nodes on the network.

Many processes use the NetBIOS interface. For example, a client's redirector uses NetBIOS to communicate with other NetBIOS computers on the network. When you add new computers to your network, NetBIOS creates logical names (i.e., NetBIOS names) for those computers. NT uses NetBIOS to run NetBIOS applications, such as Lotus Notes.

Winsock
Traditionally, PCs have used the NetBIOS interface, and UNIX machines have implemented sockets. NT 4.0, however, supports both NetBIOS and 32-bit Winsock 2.0. Like NetBIOS, Winsock is an API that NT uses to send and receive data on a network. NT implements Winsock as a DLL.

Winsock provides a standard interface for several transport protocols (including TCP/IP, IPX, DecNET, and XNS) and supports stream (TCP) and datagram (UDP) sockets. NT's OS uses Winsock to support services for Macintosh. Client applications use Winsock to communicate with the TCP/IP stack. Many Winsock applications are available, including terminal emulation software (e.g., Telnet), file transfer utilities (e.g., FTP), SQL Server client applications, Simple Network Management Protocol (SNMP), Simple Mail Transfer Protocol (SMTP), and email clients.

NetDDE
To grasp the NetDDE concept, you first need to look at Dynamic Data Exchange. DDE is a protocol that establishes a link between two applications on the same computer so that they can exchange data. To establish this link, the applications start a DDE conversation. The application initiating the conversation is the DDE client; the application responding is the DDE server. An application can participate in several DDE conversations simultaneously, acting as a DDE client in some conversations and a DDE server in others.

NetDDE uses NetBIOS to extend DDE capabilities so that two applications on different computers can exchange data. However, before NetDDE can be used, a NetDDE share must be created on the machine. This process is similar to an administrator creating a shared folder on the server so that clients can connect to it. Some NetDDE applications automatically create a NetDDE share; others do not. For those NetDDE applications that do not create a share, you can use NT's Clipboard Viewer or ddeshare.exe utility to create a share. Screen 1 shows the ddeshare.exe utility. You can find information about the shares in the Registry entry HKEY_CURRENT_USERSoftwareMicrosoftNetDDEDDE Trusted Shares.

NT lists two NetDDE services in Control Panel Services: Network DDE (Network Dynamic Data Exchange) and Network DDE DSDM (DDE Share Database Manager). You need to manually start either service; when you launch one NetDDE service, both services will start. Examples of applications that use NetDDE include Clipboard Viewer, and the game Hearts.

RPCs
RPCs take advantage of three other IPC mechanisms (named pipes, NetBIOS, and Winsock) to facilitate communication between a client and server. Sun Microsystems originally did a lot of work on RPC. Later, the Open Software Foundation (OSF) gave RPC a boost by making it the fundamental communications technology of its distributed computing environment (DCE). Microsoft also has done major work on its RPC, which is compatible with OSF's RPC. NT, Windows 95, Windows 3.x, and MS-DOS support Microsoft's RPC.

RPC is based on structured programming concepts and is popular among developers of distributed applications. In structured programming, a program consists of a main logic block (i.e., the backbone), which doesn't change very often, and procedures, which change more frequently. Developers try to create an application in which the backbone calls on procedures that they can easily modify without changing the main logic block. Developers achieve this goal with one of three designs:

In the Windows 3.x environment, developers use the second design, storing the procedures in DLLs. The implementation of DLLs is similar to the implementation of modules of self-contained code in NT's modular architecture. Just as NT developers can add, update, or remove modules of self-contained code without changing NT's OS, program developers can add, update, or remove DLLs without changing the program's backbone.

Developers use RPCs in programs based on the third design. For example, NT uses RPCs when it runs applications that store the backbone and procedures on separate computers. (When an application's client and server components reside in different locations on the same computer, NT uses local procedure calls­LPCs.) RPC offers enhanced performance because it shares the computational chores with remote machines. Depending on the type of application, clients might notice a significant improvement in performance. For example, responses to database queries might speed up.

Microsoft's RPC is an essential part of NT networking. Without RPC, you could not boot your OS or communicate on the network. Several systems management tools also use RPC. For example, NT uses RPC in Server Manager, User Manager, Performance Monitor, and Event Viewer.

DCOM
Microsoft's object technology has evolved over the years from DDE and Object Linking and Embedding (OLE) to component object model (COM) to ActiveX (COM enabled for the Internet) and DCOM (also known as networked OLE). DCOM enables applications to use services in a distributed and cross-platform environment. To understand DCOM, you need to know about COM.

Suppose a client wants to communicate with another process on the same machine. Without COM, the client must use an intermediary component to communicate because the client cannot call the process directly. With COM, the client can communicate directly with the process. COM facilitates direct communication by redefining how clients and their processes can interact.

Just like RPC extends the DLL concept from local machines to different computers, DCOM extends the COM concept so that clients can communicate directly with other processes on different computers on a LAN, a WAN, or the Internet. DCOM uses the same tools and technologies as COM to integrate distributed applications across multiple computers. DCOM is not proprietary to Microsoft; it is platform independent and supports all 32-bit DCOM-aware applications. Multiple platforms that support DCOM include NT, Win95, UNIX, and Macintosh.

Before you can run a DCOM-aware application, you must configure the properties for both the client and server application. Microsoft provides a DCOMCNFG utility in NT 4.0 to configure DCOM properties. This utility lets you configure 32-bit applications for DCOM communication across the network. No icon will appear for this tool, but you can type DCOMCNFG at the command prompt to start the utility. Screen 2 shows some of the DCOM applications you can configure with DCOMCNFG.

DCOM offers several advantages over other IPC mechanisms. The first advantage is that DCOM provides a higher level of security. Administrators can decide who can launch and access applications, where applications will run, and who can install or edit the configuration of existing OLE servers. You can also control permissions and encryption for connections between applications.

Another advantage is you don't need to add network support for applications because DCOM applications do not distinguish whether a process is local or remote. Only the OS knows where the process is running.

Finally, DCOM is user friendly. You can use existing tools to make existing applications DCOM-aware. In addition, writing new DCOM applications is easy because, unlike writing RPC applications, you don't need extensive networking knowledge.

Invisible But Important
You might not be aware of their presence, but NT's primary IPC mechanisms are hard at work in your distributed computing network. These IPC mechanisms facilitate communication at all network levels. They help ensure that your network runs properly.