Windows 95 includes several mechanisms that support distributed computing. Typically, distributed computing means that a computing task 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 math problem that would take a month to solve. But with distributed computing, 50 computers could work on the same math 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 95 includes the following interprocess communication (IPC) mechanisms to support distributed computing: Windows Sockets, Remote Procedure Calls (RPC), NetBIOS, named pipes, and mailslots. The following sections provide details about these IPC implementations in Windows 95.
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 FTP and SNMP. In Windows 95, sockets support is also extended to IPX/SPX.
Windows Sockets in Windows 95 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:
Sockets provide reduced overhead when compared with a NetBIOS protocol. Non-NetBIOS native protocols such as TCP/IP and IPX/SPX require a NetBIOS interface and mapping layer. This extra NetBIOS software adds processing time and also adds a header to the data frame sent on the wire. For example, when the NetBIOS interface is used over TCP/IP, a NetBIOS header is added to the frame before the TCP and IP headers. Workstations running only TCP/IP cannot see this frame. However, when sockets are used, the frame is sent using TCP/IP without the addition of a NetBIOS header.
In TCP/IP, the internetwork address is the IP address of the workstation and the software process address is the port number. Source and destination IP address and port numbers are fields in the TCP/IP packet structure. In IPX/SPX, the internetwork address is the combination of the IPX network ID and the media access control (MAC) address of the network adapter, and the software process address is the IPX Socket number. Source network, destination network, node, and socket numbers are fields in the IPX/SPX packet structure.
Note IPX Sockets are not the same as Windows Sockets.
For a bidirectional path, a Windows Sockets application specifies the following, depending on the protocol.
Protocol | Source and destination socket identifiers |
TCP/IP bidirectional path | IP address and port number of the source |
IPX/SPX bidirectional path | Network ID, MAC address of the network adapter, IPX socket number |
The following table describes the supporting files for 16-bit and 32-bit Windows Sockets over TCP/IP and 32-bit Windows Sockets over IPX/SPX.
Windows Sockets Supporting Files
File | Description | Comments |
WINSOCK.DLL | 16-bit Windows Sockets | Provides backward compatibility with existing 16-bit TCP/IP Windows Sockets applications such as ping |
WSOCK.VXD | Virtualized Windows Sockets | Supports 16-bit Windows Sockets and 32-bit TCP/IP and IPX/SPX Windows Sockets |
WSTCP.VXD | Windows Sockets over TCP/IP1 | Supports 16-bit Windows Sockets and 32-bit TCP/IP Windows Sockets |
WSOCK32.DLL | 32-bit Windows Socket | Supports 32-bit TCP/IP Windows Socket applications such as telnet and 32-bit IPX/SPX Windows Socket applications |
WSIPX.VXD | Windows Sockets over IPX/SPX2 | Supports 32-bit IPX/SPX Windows Sockets |
1 Windows Sockets over TCP/IP are STREAMS-based over TCP and datagram-based over UDP.
2 Windows Sockets over IPX/SPX are STREAMS-based over SPX and datagram-based over IPX.
Popular programs such as ftp or telnet use Windows Sockets. If you are interested in developing a Windows Sockets 1.1 application, specifications for Windows Sockets are available on the Internet from ftp.microsoft.com, on CompuServe® in the MSL library, and in the Microsoft Win32 Software Development Kit.
The Microsoft RPC facility is compatible with the Open Software Foundation (OSF) Data Communication Exchange (DCE) specification for remote procedure calls and is completely interoperable with other DCE-based RPC systems such as those for HP and IBM AIX® systems. (The RPC facility is not compliant with the OSF specification — that is, it doesn't start with the OSF source code and build on it.)
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 shown in the following diagram, Windows 95 provides RPC client support over the NetBIOS, named pipes, and Windows Sockets interfaces.
RPC client support in Windows 95
The following diagram shows how Windows 95 provides RPC server support over NetBIOS and Windows Sockets. There is no server support for RPC over named pipes. With a named-pipes RPC application, the named-pipes client can be run on the computer running Windows 95 but the named-pipes server must be set up on a LAN Manager server or Windows NT computer.
RPC server support in Windows 95
NetBIOS can be used in Windows 95 for communication between protocols and upper-level software such as the redirector and server service. NetBIOS provides backward compatibility for existing NetBIOS applications. NetBIOS 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 95. The additional NetBIOS driver and DLL enable Windows 95 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 95 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 95 (NETBIOS.DLL and VNETBIOS.386) is supported by all three protocols shipped with Windows 95.
The architecture for NetBIOS over the various protocols is described with the respective protocols earlier in this chapter.
Named pipes provides backward compatibility with existing LAN Manager installations and applications. Windows 95 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 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 (but is not necessarily) involved in making the pipe available to other workstations.
Although named pipes are usually used bidirectionally, the 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 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 provide backward compatibility with existing LAN Manager installations and applications. Mailslot APIs in Windows 95 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.
Mailslots can be used for one-to-one or one-to-many communication. A mailslot can be created on any network workstation. 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 only be sent to a mailslot that was created on a server. (Notice that Windows 95 does not use first-class messaging.)
Second-class delivery is a datagram-based, unguaranteed data transfer for one-to-one and many-to-one communication. Messages designated as second-class delivery can be sent to a mailslot that was created on any workstation, or even on multiple workstations, if the message size is 400 bytes or less.
Windows 95 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 95 uses second-class mailslots for WinPopup messages and browsing.