Chapter 29 - Windows 98 Network Architecture

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This chapter presents information about the architecture for the networking components in Microsoft Windows 98.

See Also

• For more information about configuring and using network adapters and protocols, see Chapter 15, "Network Adapters and Protocols." 

• For more information about configuring and using Windows 98 on Microsoft networks, see Chapter 16, "Windows 98 on Microsoft Networks." 

• For more information about configuring and using Windows 98 on third-party networks, see Chapter 17, "Windows 98 on Third-Party Networks." 

• For more information about configuring and using Dial-Up Networking and Point-to-Point Tunneling Protocol (PPTP), see Chapter 19, "Remote Networking and Mobile Computing." 

Overview of Windows 98 Network Architecture

Windows 98 provides multiple, simultaneous connections to a variety of networks (Windows NT, Novell NetWare, and others) and a variety of resources (files, programs, printers, host systems, and mail systems) over most popular media (Ethernet, Token Ring, X.25, ATM, and ISDN) from almost any location.

Windows 98 networking capabilities are implemented using a high-performance, reliable, and open architecture based on the Windows Open Services Architecture (WOSA) specification. This approach provides users with a consistent interface to different services on the front end, while giving system administrators the flexibility to mix and match multiple services on the back end.

Open Systems Interconnection Model

The modular networking architecture of Windows 98 is based on two industry standard models for a layered networking architecture, namely the International Standards Organization (ISO) model for computer networking, called the Open Systems Interconnection (OSI) Reference Model, and the Institute of Electrical and Electronics Engineers (IEEE) 802 model. Windows NT and Windows for Workgroups are also designed according to these standard models. The ISO OSI and IEEE 802 models define a modular approach to networking, with each layer responsible for some discrete aspect of the networking process. They are only models; they do not correspond exactly to any existing network. However, they can help you understand how networks function in general.

The OSI model describes the flow of data in a network, from the lowest layer (the physical connections) up to the layer containing the user's applications. Data going to and from the network is passed from layer to layer. Each layer is able to communicate with the layer immediately above it and the layer immediately below it. In this way, each layer is written as an efficient, streamlined software component. When a layer receives a packet of information, it checks the destination address, and if its own address is not there, it passes the packet to the next layer.

When two computers communicate on a network, the software at each layer on one computer assumes it is communicating with the same layer on the other computer. For example, the transport layer of one computer assumes that it is communicating directly with the transport layer on the other computer. However, the actual connection occurs only at the physical layer, as Figure 29.1 shows. The transport layer on the first computer has no regard for how the communication actually passes through the lower layers of the first computer, across the physical media, and then up through the lower layers of the second computer.

Figure 29.1 shows the OSI model.

 

Figure 29.1 Layers in the OSI Model 

The OSI model includes seven layers:

• The application layer represents the level at which applications access network services. This layer represents the services that directly support applications, such as software for file transfers, database access, and electronic mail. 

• The** **presentation layer translates data from the application layer into an intermediary format. This layer also manages security issues by providing such services as data encryption, and compresses data so that fewer bits need to be transferred on the network. 

• The session layer allows two applications on different computers to establish, use, and end a session. This layer establishes dialog control between the two computers in a session, regulating which side transmits, as well as when and how long it transmits. 

• The transport layer handles error recognition and recovery. When necessary, it also repackages long messages into small packets for transmission and, at the receiving end, rebuilds packets into the original message. The receiving transport layer also sends receipt acknowledgments.

• The network layer addresses messages and translates logical addresses and names into physical addresses. It also determines the route from the source to the destination computer and manages traffic problems, such as switching, routing, and controlling the congestion of data packets. 

• The data link layer packages raw bits from the physical layer into frames (logical, structured packets for data). This layer is responsible for transferring frames from one computer to another, without errors. After sending a frame, it waits for an acknowledgment from the receiving computer. 

• The physical layer transmits bits from one computer to another and regulates the transmission of a stream of bits over a physical medium. This layer defines how the cable is attached to the network adapter and what transmission technique is used to send data over the cable.

The IEEE 802 model defines low-level protocol standards at the physical and data link layers of the OSI model, dividing the data link layer into two sublayers: logical link control (LLC) and media access control (MAC). Figure 29.2 compares the IEEE 802 model and the lower layers of the OSI model.

 

Figure 29.2 IEEE 802 model compared to the OSI model 

The LLC sublayer performs the following tasks:

• Link establishment and termination 

• Frame control 

• Frame sequencing 

• Frame acknowledgment 

The MAC sublayer performs the following tasks:

• Media access management 

• Frame delimiting 

• Frame error checking 

• Frame address recognition 

Windows 98 Networking Model

Figure 29.3 shows the layered components that make up the Windows 98 networking model.

Figure 29.3 Windows 98 network architecture 

These layers correspond roughly to the layers in the OSI model, as the following list describes:

• The network providers, Installable File System (IFS) Manager, and redirectors provide functionality described in the application, presentation, and session layers of the OSI model. 

• The transport protocols provide functionality described in the transport and network layers of the OSI model. 

• Network driver interface specification (NDIS) and the network adapter drivers provide functionality described in the data link layer of the OSI model. 

The following sections describe these elements of the Windows 98 network architecture, beginning with redirectors. Network providers are described in "Multiple Network Support" later in this chapter.

Redirectors and Installable File System Manager

A network redirector provides mechanisms to locate, open, read, write, and delete files and submit print jobs. It also makes available such application services as named pipes and mailslots. When an application needs to send or receive data from a remote device, it sends a call to the redirector. The redirector provides the functionality of the application and presentation layers of the OSI model.

The redirectors are included in the Windows 98 network client software as the following file system drivers:

• In Client for Microsoft Networks, the redirector (Vredir.vxd) supports all networks based on Microsoft networking, which use the server message block (SMB) file sharing protocol. 

• In Microsoft Client for NetWare Networks, the redirector (Nwredir.vxd) supports NetWare networking products, which use the NetWare Core Protocol (NCP) file sharing protocol. 

Windows 98 also supports network redirectors created by other network vendors.

The Installable File System (IFS) Manager controls file I/O transfers for all the file systems. Each 32-bit, protected-mode redirector is implemented as a file system driver. The redirector works with the IFS Manager to map local names to network devices and to decide whether the application needs a local or remote device. For more information about IFS Manager, see Chapter 28, "Windows 98 Architecture."

In Client for Microsoft Networks, the redirector for Microsoft networks formats an application's request into SMB packets. In Microsoft Client for NetWare Networks, the NetWare redirector formats requests into NCP packets. In both cases, the data packet is then passed by the protocol to the adapter driver.

Windows 98 provides two server services for peer resource sharing:

• File and Printer Sharing for Microsoft Networks (the Windows 98 SMB-based server, Vserver.vxd), which supports resource sharing among all computers on the network that use the SMB file sharing protocol. 

• File and Printer Sharing for NetWare Networks (the Windows 98 NCP-based server, Nwserver.vxd), which supports resource sharing among all computers on the network that use the NCP file sharing protocol. 

Multiple Network Support

The Windows 98 modular network provider interface, as described in this section, supports concurrent communication with several different networks. For example, a computer can have simultaneous connections to computers running Windows 98 peer resource sharing services, to servers for Windows NT and NetWare networks.

In addition to the Windows 98 network client and peer sharing components, Windows 98 supports upgrading from several different third-party network clients. For a list of these clients, see Chapter 14, "Introduction to Networking Configuration."

Most of these network clients can be installed along with protected-mode Windows 98 networking components. Windows 98 does not include the supporting files for these networks; you must obtain them from the network vendor. For more information about these network clients, see Chapter 17, "Windows 98 on Third-Party Networks."

Multiple network support in Windows 98 consists of these components, as described in the following sections:

• Win32 WinNet application programming interface (API). 

• Multiple provider router and service provider interface (SPI). 

• Network providers (including the WinNet16 interface). 

Figure 29.4 shows the architecture for multiple network support.

Figure 29.4 Multiple network support in Windows 98 

Win32 WinNet Interface for Applications

The Win32 WinNet interface in Windows 98 provides an API that software developers can use to create single versions of applications that run unmodified on different networks. Applications that use Win32 APIs can take full advantage of all Windows 98 performance enhancement features. Win32-based applications can utilize multitasking, Win32 APIs, long file name support, separate message queues, and memory protection. Each Win32-based application runs in its own fully protected, private address space, preventing it from causing the operating system or other applications to fail and preventing interference from errors generated by other applications.

The Win32 WinNet interface is the successor to the WinNet16 interface introduced in Windows 3.0 and enhanced in Windows 3.1.

The expanded WinNet API set includes the following:

• Support for the Win32 WinNet APIs as defined in Windows NT. This set of functions and the other Win32 APIs together provide all the commonly used capabilities required by applications. 

• Support for the Win32 WinNet APIs for browsing network resources (directories, printers, and other resources). This includes consistent handling of authentication requirements across multiple networks and support for the NetWare server security model. 

• Backward compatibility with Windows for Workgroups 3.11 and support for networks that use a WinNet16 network driver. 

Multiple Provider Router and Service Provider Interface

The multiple provider router in Windows 98 exports the Win32 WinNet APIs to applications. It provides seamless access to network services and resources, and it supports a way to access a single WinNet16 network driver. It routes incoming network requests to the appropriate network provider, using the same interface, whether one or more network providers are installed.

Features common to all networks are implemented once in the multiple provider router, reducing the code base for each network provider and ensuring common behavior among networks. For example, network providers do not implement persistent connections — this feature is implemented in the multiple provider router and is entirely transparent to a network provider.

Windows 98 uses an open, modular service provider interface (SPI) to allow multiple 32-bit network providers to be installed in Windows 98 simultaneously. The service provider interface is a single, well-defined set of functions used by Windows 98 to request network services to browse servers, connect to and disconnect from servers, and so on. The multiple provider router communicates with the network providers using the service provider interface.

The service provider interface provides the needed network services to honor a Windows 98 request for network-specific services. This model is similar to the Windows 98 design for various device driver interfaces: a well-defined set of interfaces used by the operating system, with services provided by a device driver (often written by another vendor) to honor requests. These requests are then passed to the network providers.

The service provider interface enables Microsoft or other network providers to integrate varied network services seamlessly into Windows 98. The service provider interface ensures that all supported networks are identically accessed and managed through Network Neighborhood and other user interface components.

Network Providers

Windows 98 uses an open, modular network provider interface to allow multiple network support simultaneously. Key benefits of the network provider interface architecture are the following:

• An open interface allowing any network vendor to supply tightly integrated support for Windows 98. 

• Identical access to and management of network resources and components through the Windows 98 user interface, including Network Neighborhood and the Network option in Control Panel. 

The network provider API calls are used by applications to request network services. Windows 98 passes a network provider call to the appropriate network provider, which then supplies the requested network service.

The network provider is a network-specific driver that implements the service provider interface call from the multiple provider router. The functions provided include authenticating users when they access a network server, managing passwords, adding or removing server connections, and browsing network resources.

Windows 98 includes the following network providers:

• Msnp32.dll for Microsoft networks. 

• Nwnp32.dll for NetWare networks. 

• Winnet16.dll for a single 16-bit network provider that uses WinNet16 APIs. 

Windows 98 also supports any number of other 32-bit network providers, which must be supplied by other network vendors.

The Windows 98 system logon is an example of a network service provided by the network provider interface. Each network provider can provide a unique logon dialog box to suit the needs of its network server security model. After the logon is validated by the requested server, this information is passed back to Windows 98, which can then use this password to unlock any network resource linked to the logon validation. In this way, Windows 98 can accommodate the various ways that network servers provide their services, yet still offer a consistent user interface.

For example, the following summarizes the internal processes when a user double-clicks the Entire Network icon in Network Neighborhood:

1. The Windows 98 user interface generates a Win32-based network API call to enumerate servers and resources on the network. 

2. The multiple provider router receives the API call and submits a service provider interface call to all the available network providers. 

3. Each network provider browses its individual networks and returns the list to Windows 98, which displays all the networks and their hierarchies in the Entire Network window. 

Because of the network provider support in Windows 98, users can specify server name strings in a drive connection dialog box using the syntax to which they are accustomed. A network provider knows how to correctly interpret the syntax of its own server name strings. The server name string is the syntax used by a particular network operating system to specify a shared disk resource. Microsoft network-compatible networks use the universal naming convention (UNC) format (\\server_name\share_name).

However, because the network provider knows how to interpret server name strings, users who are accustomed to using the NetWare server syntax (server_name/volume_name:directory_name) can type such server names wherever required in Windows 98 to access NetWare server resources. The Windows 98 user interface and the net command also support UNC names for connecting to NetWare resources.

Network Provider for MS Networks

The network provider that supports Microsoft networks (Msnp32.dll) provides access to SMB-based Microsoft network resources using the Windows 98 user interface, such as Windows Explorer, Network Neighborhood, Control Panel, and other Windows-based applications.

As Figure 29.5 shows, Msnp32.dll provides the Microsoft network-specific dialog boxes (such as the Windows NT domain logon dialog box) and code to resolve a service provider interface call from the multiple provider router to a call to Client for Microsoft Networks.

Figure 29.5 Network provider for Microsoft networks 

Notice that there are three arrows, two going through IFS Manager and one going directly to Client for Microsoft Networks.

• When a network request is for a generic function, such as adding a connection, the call is submitted to the IFS interface. 

• When a network request is specific to a redirector, such as logging on or browsing a server, the call is sent to Client for Microsoft Networks. 

The network provider supports the following functions on Microsoft networks:

• Browsing Microsoft networks. 

• Logging on to and off of a Windows NT or LAN Manager domain. The Microsoft network provider provides authentication services for validation by a domain controller and the ability to change the domain password using the Passwords option in the Windows 98 Control Panel. 

• Adding and removing connections. The Microsoft network provider allows mapped drive and printer connections and UNC connections to SMB-based network resources. 

Network Provider for NetWare Networks

Figure 29.6 shows the network provider that supports NetWare networks. The network provider (Nwnp32.dll and its support library, Nwnet32.dll) provides access to NCP-based NetWare network resources using Windows Explorer, Network Neighborhood, Control Panel, and other Windows-based applications.

Figure 29.6 Network provider for NetWare networks 

The network provider supports the following functions on NetWare networks:

• Browsing NetWare networks. Bindery-based NetWare networks (versions 2.15 and later, 3.x, and 4.x with bindery emulation) use a Server-Volume-Directory hierarchy. 

• Logging on to and off of a NetWare network, providing dialog boxes for network logon, and performing attachments to bindery-based servers. 

• Adding and removing connections, allowing remote drive and printer connections using the NetWare format (server/volume:) and the UNC connections to NCP-based network resources (mapped drive or printer port, and \\server\share). 

WinNet16 Interface

The WinNet16 interface, shown in Figure 29.7, is the earlier set of network-independent APIs included in Windows 3.1 and Windows 95. WinNet16 provides such simple functionality as connecting to a drive letter or redirecting a printer port to a network printer. Windows 98 provides support for using a single WinNet16 driver.

 

Figure 29.7 WinNet16 interface 

If a network vendor provides a WinNet16 network driver developed for Windows 3.1 but has not written a 32-bit network provider and file system driver for Windows 95 or Windows 98, using the WinNet16 interface and Winnet16.dll is the only way to support that network in Windows 98. The WinNet16 driver that currently works with Windows 95 can be used without modification under Windows 98, using the Winnet16.dll.

If Windows 98 Setup detects a Windows 95 or Windows 3.1 installation that uses a WinNet16 network driver and there is no 32-bit network provider available, Windows 98 Setup keeps the 16-bit network driver in place and provides network functionality with the 16-bit network driver installed as the primary network.

Multiple Network Example

Figure 29.8 shows an example of multiple networks. In this example, the user has installed two Windows 98 network clients (Client for Microsoft Networks and Client for NetWare Networks) and has also installed support for a 32-bit Banyan VINES client.

Figure 29.8 Network drive connection request with multiple networks installed 

Banyan VINES uses the StreetTalk syntax (item@group@organization) to specify file service names. When the multiple provider router receives a request to connect to docs@marketing@corp from a network drive connection dialog box in Windows 98, the multiple provider router submits the request to all installed network providers. The Banyan VINES network provider, Vnsnet32.dll, queries StreetTalk to identify the path as a Banyan object. Then the network provider passes the connection request to the VINES file system driver.

Architecture for the Network Driver Interface Specification

The network driver interface specification (NDIS) describes the interface that network adapter card drivers use to communicate with underlying network interface cards, with overlying protocol drivers, and with the operating system.

Windows 95 included support for NDIS 2.x and 3.1 network adapter card and protocol drivers. Windows 98 still supports NDIS 2.x and 3.1 drivers, and adds support for extensions defined in NDIS 4.0 and NDIS 5.0.

This section provides technical background information about NDIS support in Windows 98.

NDIS Miniport Architecture

In releases of NDIS before 3.1, adapter drivers implemented not only the media access functionality that was specific to the network adapter card, but also the media access functionality common to all NDIS drivers.

For NDIS 3.1 and later adapter miniport drivers, the Windows 98 NDIS wrapper implements the functionality common to all NDIS drivers. Thus, the miniport driver provided by the adapter manufacturer must implement only the functionality specific to the network adapter. This includes specific details such as establishing communications with the adapter, turning on and off electrical isolation for Plug and Play, providing media detection, and enabling any value-added features the adapter might contain.

Figure 29.9 shows the architecture for NDIS 3.1 or later network adapter and protocol drivers.

 

Figure 29.9 Windows 98 architecture for NDIS 3.1 or later protocols 

Windows 98 provides miniport binary compatibility between Windows 98 and Windows NT 3.5 and later, so miniport drivers written for one operating system can also be used on the other.

NDIS Architecture for Connection-Oriented Networks and ATM

NDIS 5.0 adds support for connection-oriented networks. This section gives a brief overview of connection-oriented networks and describes the general NDIS architecture for them. Next, it describes the specific NDIS architecture for asynchronous transfer mode (ATM) networks.

NDIS Support for Connection-Oriented Networks

On connectionless networks such as Ethernet networks, computers do not wait to establish a connection before sending packets; they simply forward the packets. Both the sending and receiving computers then perform complex error-checking to ensure the packets arrived at their destination. In contrast, on connection-oriented networks such as Integrated Services Digital Network (ISDN) or ATM networks, two computers must establish a connection (sometimes called a virtual circuit [VC]) before either computer can transmit any data. NDIS 5.0 supports multiple virtual circuits on one network adapter. Computers use signaling protocols to establish virtual circuits.

On ATM networks, the signaling protocols may establish a particular Quality of Service (QoS), or level of service, during call setup. The QoS parameters defined by the ATM standards are used to negotiate such network 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.10 shows how Windows 98 implements support for connection-oriented networks.

Figure 29.10 Windows 98 architecture for connection-oriented networks 

NDIS 5.0 describes three entities in support of connection-oriented media:

Call manager. The call manager implements the media-specific signaling protocol for virtual circuit (connection) management on connection-oriented networks.

Connection-oriented miniport driver. Just as the connectionless local area network (LAN) miniport driver described in "NDIS Miniport Architecture" earlier in this section provides the hardware interface to connectionless media, the connection-oriented miniport driver provides the hardware interface to connection-oriented media.

Note With NDIS 5.0, network adapter driver manufacturers can also create a single driver that provides both call manager and miniport functionality.

Connection-oriented protocol. A connection-oriented protocol uses NDIS to establish and tear down virtual circuits and to send and receive data over those virtual circuits.

Windows 98 Support for ATM Networks

Figure 29.11 shows Windows 98 support for ATM networks.

Figure 29.11 Windows 98 support for asynchronous transfer mode 

Windows 98 contains the following components to support ATM:

Support for ATM miniport drivers. Windows 98 includes integrated support for many ATM miniport drivers. Microsoft distributes a driver development kit (DDK) and provides compatibility testing programs to ensure support for a variety of ATM adapters.

User-Network Interface (UNI) 3.1 call manager. This call manager complies with the ATM Forum's UNI specification for signaling on an ATM network.

ATM LAN Emulation 1.0. Windows 98 includes a LAN Emulation (LANE) 1.0 module, which works with the LAN Emulation Services on an ATM switch to translate Ethernet addresses into ATM addresses, thus allowing LAN applications and protocols to function transparently on an ATM network.

Native ATM access for kernel-mode drivers. NDIS 5.0 provides an API by which any kernel mode driver can establish and use connections on an ATM network, with full support for ATM's Quality of Service. This will also allow Microsoft to expose native ATM access to Win32-based applications through such network programming APIs as Windows Sockets version 2.0.

Architecture for Network Protocols

Microsoft Windows 98 includes support for Transport Control Protocol/Internet Protocol (TCP/IP), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) – compatible protocols, and NetBEUI. The following sections describe how support for each type of protocol is implemented in Windows 98.

Architecture for MS TCP/IP

TCP/IP is a popular routable protocol for wide-area networks (WANs). The TCP/IP module, Vtcp.vxd, is accessible through the Windows Sockets interface or through the NetBIOS interface. For information about Windows Sockets and interprocess communication mechanisms, see "Architecture for Interprocess Communications" later in this chapter.

Figure 29.12 shows the TCP/IP architecture.

Figure 29.12 Windows 98 architecture for Microsoft TCP/IP 

Architecture for the IPX/SPX-Compatible Protocol

The Microsoft IPX/SPX-compatible protocol uses the Nwnblink.vxd module to support NetBIOS over IPX and to support the NetBIOS programming interface. Figure 29.13 shows the architecture for the IPX/SPX-compatible protocol.

Figure 29.13 Windows 98 architecture for IPX/SPX-compatible protocol 

The Microsoft IPX/SPX-compatible protocol is compliant with NDIS 3.1 and later and enables computers running Windows 98 to communicate over a routable IPX-compatible protocol. This protocol can use Novell NetWare servers configured as routers (as well as other IPX routers) to transfer its packets across LANs to access resources on other computers running Windows 98.

Architecture for the NetBEUI Protocol

As Figure 29.14 shows, the NetBEUI module, Netbeui.vxd, implements the NetBIOS framing protocol.

 

Figure 29.14 Windows 98 architecture for NetBEUI protocol 

Architecture for Clients and Peer Servers

You can install either or both of the 32-bit, protected-mode networking clients, Client for Microsoft Networks and Client for NetWare Networks. The following sections describe the architecture for these two clients and the related peer servers.

Figure 29.15 shows the architecture for both network clients.

Figure 29.15 Architecture for Client for NetWare Networks used with Client for Microsoft Networks 

Client for MS Networks Architecture

Windows 98 provides a 32-bit, protected-mode file system driver to support all Microsoft networking products that use the SMB file sharing protocol. This includes LAN Manager, Windows NT, Windows for Workgroups 3.x, Workgroup Add-on for MS-DOS, Windows 95, and Windows 98. Also supported are network products from other vendors using the Microsoft network standard, such as IBM LAN Server, IBM OS/2 Warp Server, and Samba servers. Figure 29.16 shows the architecture for Microsoft networking.

Figure 29.16 Windows 98 architecture for Microsoft networking 

Client for Microsoft Networks supports connectivity over any NDIS protocol that supports a NetBIOS interface and is accessible through Vnetbios.vxd. The protected-mode protocols provided with Windows 98 that support a NetBIOS interface are the following:

• NetBEUI using Netbeui.vxd 

• NetBIOS over TCP/IP using Vnbt.vxd and the TCP/IP components Vtcp.vxd and Vip.vxd 

• NetBIOS over IPX/SPX using Nwnblink.vxd and Nwlink.vxd 

Client for Microsoft Networks also supports connectivity over IPX/SPX using Nwlink.vxd without the NetBIOS interface.

Client for NetWare Networks Architecture

You can use Client for NetWare Networks in an environment where all that is needed is a 32-bit client to connect to existing NetWare servers (for example, if there is no need for SMB-based peer resource sharing services). Figure 29.17 shows the architecture for this configuration.

 

Figure 29.17 Architecture for Client for NetWare Networks as the sole client 

For more details about the architecture for Windows 98 with Novell-supplied network clients, see Chapter 17, "Windows 98 on Third-Party Networks."

Architecture for Peer Resource Sharing

Windows 98 includes components to support file and printer sharing on Microsoft networks and NetWare networks.

When File and Printer Sharing for Microsoft Networks is installed, the Windows 98 SMB server (Vserver.vxd) is added to the computer's configuration. This component supports all Microsoft networking products that use the SMB file sharing protocol. Figure 29.18 shows the basic supporting files for File and Printer Sharing for Microsoft Networks in the Windows 98 networking architecture.

Figure 29.18 Architecture for File and Printer Sharing for Microsoft Networks 

When File and Printer Sharing for NetWare Networks is installed, the Windows 98 NCP server (Nwserver.vxd) is added to the computer's configuration. Client for NetWare Networks is used to get NetWare server connection information and to enable user-level security based on a NetWare server's user accounts. Figure 29.19 shows the supporting files for File and Printer Sharing for NetWare Networks in the Windows 98 networking architecture.

Figure 29.19 Architecture for File and Printer Sharing for NetWare Networks 

For file and printer sharing services with user-level security, the security provider (Mssp.vxd or Nwsp.vxd) assists in validating user access when sharing a resource and in retrieving a user list when administrating the server. The network address book (Msab32.dll or Nwab32.dll) translates the account lists from the server and provides the Add Users dialog box for selecting which users get access rights. The file security component (Filesec.vxd) provides access control based on information in the registry. Notice that these same security components support features such as remote registry access even when file and printer sharing services are not present.

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. For more information about RSVP, see the Internet Engineering Task Force (IETF) RSVP specification at https://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 

File	Description	Comments
WinSock.dll	16-bit Windows Sockets	Provides backward compatibility with existing 16-bit TCP/IP Windows Sockets applications (Windows Sockets 1.1 interface)
Ws2thk.dll	16- and 32-bit Windows Sockets Thunk	Thunking layer to convert 16-bit Windows Sockets API to 32-bit Windows Sockets API
Wsock32.dll	32-bit Windows Sockets 1.1	Provides backward compatibility with existing 32-bit TCP/IP Windows Sockets applications (Windows Sockets 1.1 interface)
Ws2_32.dll	32-bit Windows Sockets 2.0	Windows Sockets 2.0 application programming interface
Ws2help.dll	Operating system – dependent support for Windows Sockets 2.0	Abstracts operating system – dependent functionality in Windows Sockets 2.0 API library
Msafd.dll	TDI transport service provider	Microsoft Windows Sockets 2.0 transport service provider for transport, exposing TDI interface (currently TCP/IP)
Mswsosp.dll	Windows Sockets 1.1 transport service provider	Microsoft Windows Sockets 2.0 transport service provider for Windows Sockets 1.1 – compatible transports (currently IPX/SPX). Supports only Windows Sockets 1.1 functionality.
Mswsock.dll	Windows Sockets 1.1 extensions	Microsoft extensions that are not part of general (supported by all providers) Windows Sockets 2.0 specifications but were present in Windows Sockets 1.1
Rnr20.dll	TCP/IP name space service provider	Microsoft Windows Sockets 2.0 TCP/IP name service provider.
Wsock2.vxd	Windows Sockets 2.0 transport service provider	Kernel mode support for Windows Sockets 2.0–compatible transport service providers (currently only TCP/IP)
Wsock.vxd	Windows Sockets 1.1 transport service provider	Kernel mode support for Windows Sockets 1.1–compatible transport service providers (currently only IPX/SPX)
Afvxd.vxd	TDI transport service provider	Kernel mode support for Windows Sockets 2.0 transport service provider exposing TDI interface (currently only TCP/IP)
Wshtcp.vxd	TCP/IP TDI transport support	Supports TCP/IP-specific functionality for Microsoft TDI transport service provider for Windows Sockets 2.0
Wsipx.vxd	Windows Sockets over IPX/SPX	Supports IPX/SPX Windows Sockets 1.1–compatible transport

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 https://msdn.microsoft.com/library/en-us/wcecomm/html/_wcesdk_Windows_Sockets.asp and on the MSDN compact disc.

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 150777, "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.

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

Architecture for Communications and Remote Networking

This section describes the following topics:

• Serial Communications architecture 

• Dial-Up Networking architecture 

• Point-to-Point Tunneling Protocol (PPTP) architecture 

Serial Communications Architecture

Windows 98 separates communications operations into three primary areas: Win32 communications APIs and the Telephony API (TAPI), the universal modem driver, and communications port drivers. Figure 29.28 shows the communications architecture.

Figure 29.28 Serial Communications architecture 

VCOMM is a communications device driver that provides protected-mode services allowing Windows-based applications and drivers to use ports and modems. To conserve system resources, communications drivers are loaded into memory only when in use by applications. Also, VCOMM uses Plug and Play services in Windows 98 to assist with configuration and installation of communications devices.

Figure 29.28 also illustrates the flow path for a Win16-based application to show how compatibility is maintained when hardware or software vendors replace the Windows 3.1 Comm.drv driver. The vendor-specific communications driver, however, communicates directly with the I/O port, rather than through VCOMM.

The following paragraphs describe the primary areas that make up the architecture.

Win32 communications APIs and TAPI. The Win32 communications APIs in Windows 98 provide an interface for using modems and communications devices in a device-independent fashion. Applications call the Win32 communications APIs to configure modems and perform data I/O through them. Through the Windows Telephony API (TAPI), applications can control modems or other telephony devices.

Universal modem driver. The universal modem driver (Unimodem) is a layer that provides services for data and fax modems and for voice so that users and application developers will not have to learn or maintain difficult modem AT commands to dial, answer, and configure modems. Rather, Unimodem does these tasks automatically by using miniport drivers written by modem hardware vendors.

Unimodem is both a VCOMM device driver and a TAPI service provider. Other service providers (for example, those supporting other devices, such as an ISDN adapter, a telephone on a PBX system, or an AT-command modem) can also be used with TAPI.

Port drivers. Port drivers are specifically responsible for communicating with I/O ports, which are accessed through the VCOMM device driver. Port drivers provide a layered approach to device communications. For example, Windows 98 provides a port driver to communicate with serial communications and parallel ports, and other vendors can provide port drivers to communicate with their own hardware adapters, such as multiport communications adapters. With the port driver model in Windows 95 and Windows 98, it is not necessary for vendors to replace the communications subsystem as they did in Windows 3.1.

Windows Telephony API. TAPI-aware communications applications no longer need to provide their own modem support list because interaction with a modem is now centralized by Windows 98. All communications services provided with Windows 98 use these services.

TAPI provides a standard way for communications applications to control telephony functions for data, fax, and voice calls. TAPI manages all signaling between a computer and a telephone network, including basic functions such as dialing, answering, and hanging up a call. It also includes supplementary functions, such as hold, transfer, conference, and call park found in PBX, ISDN, and other telephone systems. TAPI also provides access to features specific to certain service providers, with built-in extensibility to accommodate future telephony features and networks as they become available.

TAPI services arbitrate requests from communications applications to share communications ports and devices cooperatively. Win32-based applications can use TAPI functionality to make outgoing calls while others are waiting for incoming calls. Of course, only one call can be performed at a time, but users no longer have to close applications that are using the same communications port.

TAPI consists of two interfaces: an API that developers use to write applications and the service provider interface (SPI) that applications use to establish the connection to the specific telephone network. This model resembles the computer industry model for printers, in that printer manufacturers provide printer drivers for Windows-based applications. Figure 29.29 shows the relationship between the front-end TAPI and the back-end SPI.

Figure 29.29 Telephony API and service provider interface 

Dial-Up Networking Architecture

Windows 98 includes several new components in its Dial-Up Networking architecture. This section gives an overview of the new architecture and then breaks it down into the following areas:

• Dial-Up Networking call control 

• Dial-Up Networking data transfer 

• Point-to-Point Tunneling Protocol (PPTP) call control 

• PPTP data transfer 

For more conceptual information about Dial-Up Networking and PPTP, see Chapter 19, "Remote Networking and Mobile Computing."

Dial-Up Networking Overview

This section describes many of the components included in the Dial-Up Networking architecture, which is shown in Figure 29.30.

Figure 29.30 Dial-Up Networking architecture 

Following are descriptions of the major user-mode components in this architecture.

Rnaui.dll. An Explorer extension that implements the Dial-Up Networking folder and invokes Rnaapp.exe to dial.

Rasapi32.dll. The main Windows 98 RAS API DLL. It supports the Phonebook APIs.

Smmscript.dll. Implements the session manager modules (SMMs), which enable new dial-up protocol implementations to be rolled under the RAS API and the user interface.

Rnanp.dll. A Windows 98 network provider DLL.

Directcc.exe. The Direct Cable Connect alternative user interface for connecting computers directly, using a serial or parallel cable. The first time it is run, it creates modem entries that are hidden from the Modems option in Control Panel but appear in the System option.

Following are descriptions of the major kernel-mode components in this architecture.

Pppmac.vxd. Implements the core RAS protocols: PPP, SLIP, Asynchronous NetBEUI, and NetWare Connect.

Ndiswan.vxd. Supports network driver interface specification wide area network (NDISWAN) miniport drivers. It is installed as a protocol and appears in the Network option in Control Panel as a protocol. Each adapter that is installed is bound to the NDISWAN protocol, and NDISWAN miniports bind only to the NDISWAN protocol.

Dial-Up Networking Call Control and Data Transfer

Figure 29.31 shows how the components of Dial-Up Networking work together when Dial-Up Networking is setting up a call over a modem or ISDN device.

Figure 29.31 Call control for modems and Integrated Services Digital Network devices 

To set up a connection over a modem, a user first starts a Dial-Up Networking connection. The Dial-Up Networking engine looks for information about the telephone call in the Phonebook and then queries TAPI for the available TAPI devices. Next, it places a call on the device specified in the Phonebook entry. TAPI translates the device to the correct TAPI service provider (TSP) (in this case, the Unimodem TSP). The Unimodem TSP translates the Dial-Up Networking command to specific modem commands, and then sends the modem commands to Unimodem.vxd. Unimodem.vxd sends them to VCOMM, which sends them out a serial or parallel port to a modem.

The process is similar for an ISDN card. However, TAPI uses the WAN TSP rather than the Unimodem TSP. The WAN TSP passes the commands through NDISWAN and to the ISDN driver's TSP, and the ISDN driver's TSP translates the commands.

Figure 29.32 shows an example of what happens after a call has been set up and data is being transferred. This example shows data transfer over a modem.

Figure 29.32 Data transfer for modems 

In this example, data is sent through the Windows Sockets DLL. The TCP/IP stack then encapsulates the data in TCP and Internet Protocol (IP) and then sends it to Pppmac.vxd (the component that implements the RAS protocols). Finally, Pppmac.vxd encapsulates the packet in a PPP frame and sends it to VCOMM.

Point-to-Point Tunneling Protocol Call Control and Data Transfer

Virtual private networking (VPN) is a secure method for creating an on-demand connection between two computers in different locations. The virtual private network consists of the two computers (one computer at each end of the connection) and a route, or tunnel, over the public or private network. Virtual private networking is implemented in Windows 98 using the Point-to-Point Tunneling Protocol (PPTP).

This section describes the Windows 98 architecture that supports virtual private networking.

For more detailed information about virtual private networking, see Chapter 19, "Remote Networking and Mobile Computing."

Figure 29.33 shows call control for a PPTP connection over a modem. Contrast this diagram with Figure 29.31, which showed call control for an ordinary Dial-Up Networking connection. In Figure 29.31, the call request passes through the Unimodem TSP. In Figure 29.33, it passes through the WAN TSP instead.

 

Figure 29.33 Call control for a Point-to-Point Tunneling Protocol tunnel over a modem 

Figure 29.34 shows PPTP data transfer.

Figure 29.34 Data transfer for a Point-to-Point Tunneling Protocol tunnel over a modem 

In this example, data is transferred using Client for Microsoft Networks and sent out over a modem. It could also be transferred using Client for NetWare Networks and sent out over an Ethernet connection or an ISDN device.

The data is sent by Vredir and encapsulated in IP. As with a normal data transfer, it is sent to Pppmac.vxd. In a normal data transfer, however, the data would have been sent through the Pppmac.vxd VCOMM interface to VCOMM. Here, it is rerouted instead through the Pppmac.vxd NDISWAN interface.

From there, it travels to Netpptp.sys, the component that handles the PPTP connection. Netpptp.sys transfers the PPP data to the TCP/IP stack, where it is encapsulated in GRE (defined in RFCs 1701 and 1702.).

It is next sent back through NDIS to Pppmac.vxd, which encapsulates it in PPP and sends it through VCOMM to the serial port and, finally, to the modem.

Figure 29.35 shows the encapsulated packet that is finally sent to the modem.

 

Figure 29.35 Internet Protocol datagram containing encrypted Point-to-Point Protocol packet 

Architecture for MS Data Link Control

Windows 98 includes both a protected-mode Data Link Control (DLC) driver (Dlc.vxd), which supports 32-bit and 16-bit DLC applications, and a real-mode DLC driver (Msdlc.exe), which supports only 16-bit applications. It is used primarily to access IBM mainframe computers and Hewlett-Packard network-ready printers.

This section shows the architecture for Microsoft 32-bit and 16-bit DLC.

MS 32-bit Data Link Control

Figure 29.36 shows the architecture for Microsoft 32-bit DLC.

 

Figure 29.36 Architecture for Microsoft 32-bit Data Link Control 

MS 16-bit Data Link Control

Figure 29.37 shows the architecture for Microsoft 16-bit DLC with NDIS drivers, used with a protected-mode protocol.

 

Figure 29.37 Architecture for Microsoft 16-bit Data Link Control 

Figure 29.38 shows the architecture for Microsoft 16-bit DLC with Open Datalink Interface (ODI) network adapter drivers.

 

Figure 29.38 Architecture for real-mode Data Link Control with Open Datalink Interface network adapter drivers 

Figure 29.39 shows the architecture for real-mode DLC with NDIS 2 network adapters and IBM LanSupport.

 

Figure 29.39 Architecture for real-mode Data Link Control with NDIS 2 network adapter and IBM LanSupport 

Additional Resources 

For more information about	See this resource
Generic Quality of Service (GQoS)	https://msdn.microsoft.com/library/en-us/xpehelp/html/QOSRSVP.asp
Internet Engineering Task Force (IETF) Resource Reservation Protocol (RSVP) specification	https://www.ietf.org/
COM standard	https://www.microsoft.com/Com/default.asp
DCOM Request for Comments (RFC)	https://www.microsoft.com/com/