Architecture for Interprocess Communication

Windows 98 includes several mechanisms that support distributed computing. Typically, distributed computing means that a computing task (or process) is divided into two parts. The first part runs on the client computer and requires minimal resources. The other part of the process runs on the server and requires large amounts of data, number crunching, or specialized hardware.

Another type of distributed computing spreads the work among multiple computers. For example, one computer can work on a complex mathematical problem that would take a month to solve. But with distributed computing, 50 computers could work on the same problem simultaneously and solve it in less than a day.

In both cases, a connection between computers at a process-to-process level allows data to flow in both directions. Windows 98 includes the following interprocess communication (IPC) mechanisms to support distributed computing: Windows Sockets, remote procedure calls (RPCs), NetBIOS, named pipes, mailslots, and the Distributed Component Object Model (DCOM). The following sections provide details about these IPC implementations in Windows 98.

Windows Sockets 2.0

Windows Sockets is a Windows implementation of the widely used U.C. Berkeley Sockets API, the de facto standard for accessing datagram and session services over TCP/IP. Non-NetBIOS applications must be written to the Sockets interface to access Microsoft TCP/IP protocols. Applications written to the Sockets interface include File Transfer Protocol (FTP) and Simple Network Management Protocol (SNMP).

Windows Sockets in Windows 98 is a protocol-independent networking API tailored for use by programmers using the Windows family of products. Windows Sockets is a public specification that aims to do the following:

• Provide a familiar networking API to programmers using Windows or UNIX.
• Offer binary compatibility between heterogeneous Windows-based TCP/IP stack and utility vendors.

Support both connection-oriented and connectionless protocols.

Windows 95 included the Windows Sockets version1.1 interface. Windows 98 includes a new version of Windows Sockets, Windows Sockets version 2.0. Windows Sockets 2.0 extends the Windows Sockets 1.1 interface to provide access to networks other than TCP/IP and to support real-time multimedia communications.

Note

In Windows 95, both TCP/IP and IPX/SPX supported the Windows Sockets 1.1 interface. In Windows 98, only TCP/IP supports the Windows Sockets 2.0 interface. IPX/SPX still supports the Windows Sockets 1.1 interface.

Windows Sockets 2.0 provides the following enhancements over Windows Sockets 1.1:

Name registration and resolution.

Windows Sockets 2.0 provides an interface that applications can use to access many different name spaces, such as DNS, NDS, X.500, and SAP.

Support for multimedia.

Windows Sockets 2.0 provides several multimedia enhancements, including Quality of Service (QoS), which enables different applications to request different network characteristics.

Protocol-independent multipoint and multicast.

Windows Sockets 2.0 enables applications to transparently take advantage of the multipoint and multicast capabilities of transport stacks that provide those capabilities.

Windows Sockets 2.0 Architecture

Windows Sockets 2.0 is a Windows Open Systems Architecture (WOSA)–compliant interface that enables a front-end application and a back-end service to communicate without having to speak each other’s language.

As Figure 29.20 shows, the Windows Sockets 2.0 interface includes the following components:

• The Windows Sockets 2.0 API
• The Windows Sockets 2.0 DLL (Ws2_32.dll)
• The Windows Sockets 2.0 SPI (which defines transport providers and name space service providers)
• Layered service providers (optional)

  

  Figure 29.20 Windows Sockets 2.0 architecture

Windows Sockets 2.0 API

The Windows Sockets 2.0 API sits between the Windows Sockets 2.0 DLL and either a Windows Sockets 2.0 – based application or a Windows Sockets 1.1 DLL. It provides backward compatibility with the Windows Sockets 1.1 API and adds such new APIs as Generic Quality of Service (GQoS) APIs. For more information about the GQoS APIs, see "Generic Quality of Service and Resource Reservation Protocol" later in this chapter.

Layered Service Provider Layer

The optional layered service provider layer can be inserted between the Windows Sockets 2.0 DLL and the underlying protocol stack. It can extend the underlying protocol stack by providing additional services such as authentication, encryption, or proxy server services. In Windows Sockets 1.1, application developers added such services by replacing and renaming the Windows Sockets DLL or by inserting themselves in an application’s process address table in place of the Windows Sockets DLL. These methods will no longer work with Windows Sockets 2.0, and layered service providers should be used instead.

The Resource Reservation Protocol (RSVP), which handles QoS requests, can be implemented as a layered service provider layer but is implemented as a transport service provider in Windows 98.

Windows Sockets 2.0 SPI Transport Service Providers

Transport service providers enable applications to use a consistent interface for accessing multiple transport protocols. Above the transport service provider, the Windows Sockets 2.0 DLL takes requests from applications and sends those requests to the transport service provider. The Windows Sockets 2.0 DLL also provides traffic management. The transport service provider then supports one or more transport protocols.

In Windows 98, RSVP is implemented as a base transport provider. For more information about RSVP, see "Generic Quality of Service and Resource Reservation Protocol" later in this chapter.

Windows Sockets 2.0 SPI Name Space Service Providers

Name space service providers enable servers (services) and client applications to use a consistent interface for multiple name services. Services register with the Windows Sockets DLL, and client applications send the Windows Sockets DLL requests for the names of those services. The Windows Sockets DLL manages registration and loading of name space service providers and sends name space operations to the correct provider. Finally, the provider implements an interface with existing name services, such as Domain Name System (DNS).

Generic Quality of Service and Resource Reservation Protocol

Connectionless networks such as Ethernet networks make only a best effort to deliver packets to their destination. There is no guarantee that packets will arrive, or that they will arrive in the correct order. Instead, such protocols as TCP/IP were developed to ensure retransmission of lost packets and to ensure that out-of-order packets could be reassembled in the correct order. This is sufficient for most applications, such as e-mail. However, for newer applications, such as real-time audio and video, packets must arrive on time and in order or the transmission might be garbled.

Connection-oriented networks, on the other hand, can enable applications to request certain levels of service (Quality of Service, or QoS) such as bandwidth and reliability for specific connections. Additionally, they enable computers to set up several different connections with several different Qualities of Service. For example, on a connection-oriented network you could have two simultaneous connections: a high-delay connection to send e-mail and a high-bandwidth, low-delay connection for a videoconferencing application.

Windows 98 makes this possible through its Generic Quality of Service (GQoS) APIs and its support for the Resource Reservation Protocol (RSVP). Through the GQoS APIs, applications can request different network characteristics for a connection. RSVP then handles those requests by attempting to make bandwidth "reservations" for that connection.

This section briefly discusses GQoS and RSVP. For more information about GQoS, see the specification on http://www.microsoft.com/. See also ftp://microsoft.com/bussys/winsock/winsock2/. For more information about RSVP, see the Internet Engineering Task Force (IETF) RSVP specification at http://www.ietf.org/.

Generic Quality of Service

The Generic Quality of Service (GQoS) APIs in Windows Sockets 2.0 provide access to most common attributes of various QoS implementations without requiring specific knowledge of the underlying QoS providers. Applications can make calls to GQoS APIs and request such attributes as the following:

• Peak bandwidth (average or peak bit rate available).
• Latency (the maximum acceptable delay between transmission of a bit and its receipt by the receiver).
• Delay variation (the difference between a packet’s minimum and maximum delay).

Figure 29.21 shows the architecture of QoS.

Figure 29.21 Quality of Service architecture

As Figure 29.21 shows, multimedia applications request the QoS attributes. The Resource Reservation Protocol (RSVP) signaling provider (discussed in "Resource Reservation Protocol" later in this chapter) then negotiates with the network for the requested attributes. The packet classifier and scheduler determine when to send the packets and with what priority. Finally, the QoS-aware router forwards the packets as requested.

Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) is installed during the Windows 98 installation of Windows Sockets 2.0. It handles QoS requests, reserving network bandwidth when possible and when requested, and then ensuring that the network can provide that bandwidth. Figure 29.22 shows how RSVP works.

Figure 29.22 Resource Reservation Protocol

First, the receiving computer sends a non-RSVP request to the application server. Then the application server tells RSVP to send a PATH statement to the receiving computer. The PATH statement tells the receiving computer the path the data should follow and whether the requested characteristics are available. Next, the receiving computer sends a RESV statement, which reserves network bandwidth at each hop (at each RSVP-aware router or switch) along the way. The application server then transmits data with the required QoS characteristics.

As Figure 29.23 shows, RSVP can also be used to reserve bandwidth for multicast broadcasts. As in the previous case, the receiving computer uses RSVP to request bandwidth, and the application server sends out a PATH statement. In this case, the application server sends out only one PATH statement to multiple receiving computers, thus conserving network bandwidth. Computers on the network that did not send RSVP requests will not receive the broadcast.

Figure 29.23 Resource Reservation Protocol with multicast

Supporting Files

Table 29.1 shows Windows Sockets supporting files.

Table 29.1 Windows Sockets supporting files

If you are interested in developing a Windows Sockets 2.0 – based application, specifications for Windows Sockets 2.0 are available on the Internet from ftp://ftp.microsoft.com/ and on the MSDN compact disc. For more information, visit http://www.microsoft.com/msdn/.

Remote Procedure Calls

The Microsoft remote procedure call (RPC) facility is compatible with the Open Software Foundation (OSF) distributed computing environment (DCE) specification for remote procedure calls and is completely interoperable with other DCE-based RPC systems, such as those for Hewlett-Packard and IBM AIX systems. (The RPC facility is compatible but not compliant with the OSF specification — that is, it does not start with and build on the OSF source code).

RPC uses other IPC mechanisms, such as named pipes, NetBIOS, or Windows Sockets, to establish communications between the client and the server. With the RPC facility, essential program logic and related procedure code can exist on different computers, which is important for distributed applications.

As Figure 29.24 shows, Windows 98 provides RPC client support over the NetBIOS, named pipes, and Windows Sockets interfaces.

Figure 29.24 Remote procedure call client support in Windows 98

Figure 29.25 shows how Windows 98 provides RPC server support over NetBIOS and Windows Sockets. There is no server support for RPC over named pipes. With an RPC application using named pipes, the client can be run on Windows 98, but the server must be run on Windows NT.

Figure 29.25 Remote procedure call server support in Windows 98

NetBIOS

NetBIOS can be used in Windows 98 for communication between protocols and upper-level software, such as the redirector and server service. NetBIOS provides backward compatibility for existing NetBIOS applications. It provides a protocol-independent way of creating sessions and datagrams, and supporting name resolution over multiple protocols. NetBIOS is supported by the Microsoft TCP/IP, NetBEUI, and IPX/SPX-compatible protocols in Windows 98. The additional NetBIOS driver and DLL allow Windows 98 to be compatible with NetBIOS applications and to run software that specifically requires NetBIOS. The NetBIOS software is used only for these situations.

NetBIOS defines the interface between the redirector and the protocol layers. The NetBIOS interface is a set of function calls that allow an application (such as the redirector in the Windows 98 protected-mode network client) to use the services of a transport-layer service provider, such as the NetBEUI protocol driver.

Many network applications use NetBIOS to send commands to the protocol driver. As long as a protocol driver recognizes NetBIOS commands issued by an application, that protocol driver can be used with any NetBIOS application. The NetBIOS interface in Windows 98 (Netbios.dll and Vnetbios.vxd) is supported by all three protocols provided with Windows 98.

The architecture for NetBIOS over the various protocols is described with the respective protocols earlier in this chapter.

Client-Side Named Pipes

Named pipes provide backward compatibility with existing LAN Manager installations and applications. Windows 98 supports client-side named pipes for Microsoft networks. Server-side named pipes are not supported.

Client for Microsoft Networks makes the named pipes API available for applications that use named pipes for IPC. However, Client for Microsoft Networks does not provide named pipes support for other networks, such as Novell NetWare and Banyan VINES. A user who needs Novell NetWare or Banyan VINES named pipes support must use the real-mode terminate-and-stay-residents (TSRs) and network components provided by Novell or Banyan.

Named pipes provide an easy-to-access conduit for a one-to-one, reliable, connection-oriented data transfer between two processes. These two processes are normally differentiated as a client process and a server process. The term server as applied to the server process in a named pipe application does not refer to the "server service" that is a component of the network operating system, although the server service may be involved in making the named pipe available to other computers.

• The named pipe server process creates the pipe and manages access to it. The resources that make up the pipe are owned by the server process and physically exist on the computer where the server process is running.
• The named pipe client process uses the services of the underlying network protocols to access the remote pipe resources.

Although named pipes are usually used bidirectionally, a named pipe can be configured to allow communication in only one direction, such as from server to client.

A common use for named pipes is in client/server applications based on the Structured Query Language (SQL). The SQL client application can be run on a computer running Client for Microsoft Networks. The Microsoft SQL Server application, however, must be set up on a LAN Manager, Windows NT, or other named pipes server.

Mailslots

Mailslots provide backward compatibility with existing LAN Manager installations and applications. Mailslot APIs in Windows 98 and Windows NT are a subset of the APIs in Microsoft OS/2 LAN Manager. Client for Microsoft Networks makes the mailslots API available for applications that use mailslots for interprocess communication (IPC).

Mailslots can be used for one-to-one or one-to-many communication. A mailslot can be created on any network computer. When a message is sent to a mailslot, the sending application specifies in the mailslot message structure whether the message is to be sent using first-class or second-class delivery.

First-class delivery is a session-oriented, guaranteed data transfer for one-to-one or one-to-many communication. Messages designated as first-class delivery can be sent only to a mailslot created on a server. (Windows 98 does not use first-class messaging.)

Second-class delivery is a datagram-based, unguaranteed data transfer for one-to-one or one-to-many communication. Messages designated as second-class delivery can be sent to a mailslot created on any computer, or even on multiple computers, if the message size is 400 bytes or less.

Windows 98 and Windows NT implement only second-class mailslots, which are most useful for identifying other computers or services on a network and for wide-scale identification of a service. Windows 98 uses second-class mailslots for WinPopup messages and browsing.

Distributed Component Object Model

The Distributed Component Object Model (DCOM) extends the Component Object Model (COM) to allow components of a distributed application to communicate over the network securely and transparently.

With DCOM, application developers can create location-independent distributed applications using a language of their choice, such as Java, Microsoft Visual Basic, or Microsoft Visual C++. Network administrators can then deploy those components on Windows 98 computers, Windows NT Server computers, and Windows NT Workstation computers anywhere in the network.

DCOM provides several benefits and optimizations, including the following:

• Renders the complexity of underlying network invisible to application components.
• Provides administrative options to enable remote use of existing COM applications.
• Provides a high level of control over such security mechanisms as permissions and authentication.
• Provides two-way, symmetric communication.

DCOM is based on the COM model. COM provides a binary model for components and a protocol for communicating with components. Clients and components can communicate with one another in one of three ways:

Method 1.

If clients and components are in the same apartment, they can communicate directly. (For information about apartments, see Knowledge Base Article Q150777, "INFO: Descriptions and Workings of OLE Threading Models.")

Method 2.

If clients and components are in a different process but on the same computer, COM injects itself between the client and the component and uses a local interprocess communication (LPC).

Figure 29.26 shows how COM is used within a single computer. Component A, a client component, calls component B, a server component.

Note

Components that call other components are called client components, whereas components that are called by other components are called server components. Client and server components can reside on the same computer and be part of the same application.

Figure 29.26 Component Object Model used in a single computer

Method 3.

If the client and the component are on different computers, they still communicate with each other in the same way. However, in this case, DCOM injects itself between the client and component and uses RPC. Figure 29.27 shows this configuration.

Component A, located on one computer, uses DCOM to call component B, located on another computer.

Figure 29.27 Distributed Component Object Model used on a network

DCOM shields the client and the component from the network protocol, so the client and the component are unaffected. Thus, COM components can be reused without modification. In addition, any number of components can also be distributed across any number of computers. Also, DCOM hides the location of the component and enables components to be moved without changes to the source code and without recompilation.

To download the COM standard, visit ftp://ftp.microsoft.com/developr/drg /OLE-info/COMSpecification/.

For more information about COM, and to download the informational DCOM Request for Comments (RFC), go to http://www.microsoft.com/com/.