Chapter 1 - Windows NT Networking Architecture
The Microsoft Windows NT operating system was designed and built with fully integrated networking capabilities. These networking capabilities differentiate Windows NT from other operating systems, such as MS-DOS, OS/2, and UNIX, in which network capabilities are installed separately from the core operating system.
This chapter introduces the Windows NT networking architecture. It provides you with descriptions of the following topics.
•
The design goals and rationale for the Windows NT operating system.
•
The basic components of the Windows NT operating system architecture.
•
The basics of networking architecture in general. This includes a detailed description of the model on which Windows NT was designed, as well as the industry standards and specifications.
•
The Windows NT vertical layers and the interfaces for communication between layers.
•
The Windows NT network protocols, which enable layers on two different computers to communicate with each other.
•
Distributed processing of applications across the network and the mechanisms Windows NT uses to create connections between servers and workstations.
•
The mechanisms for sharing resources across the network, including Multiple Universal Naming Convention Provider (MUP) and Multi-Provider Router (MPR).
•
The workstation and server services.
•
How binding options work, enabling communications between network layers.
•
How Remote Access Service (RAS) works to connect remote or mobile clients to corporate networks.
•
How Services for Macintosh are built into Windows NT, allowing Apple Macintosh clients to connect to a Windows NT Server as if it were any other AppleShare server.
Top of pageTop of page
The Windows NT Layered Network Architecture
A significant difference between the Windows NT operating system and other operating systems is that the networking capabilities were built into the system from the ground up. With MS-DOS, Windows 3
.x, and OS/2, networking was added to the operating system.
By providing both client and server capabilities, a computer running Windows NT Server or Windows NT Workstation can be either a client or server in either a distributed-application environment or a peer-to-peer networking environment.
The following illustration shows the specific way Windows NT implements the OSI model.
Figure 1.9 Windows NT layered network architecture
To understand the Windows NT operating system capabilities, it is important to understand the network architecture. The networking architecture with its layered organization provides expandability by allowing other functions and services to be added.
The rest of the chapter is devoted to an explanation of the concepts and features of the Windows NT layered networking architecture, including the following topics.
•
Boundary layers
•
Network protocols
•
Streams
•
Distributed processing
•
Distributed component object model
•
Network resource access
•
Workstation service
•
Server service
•
Binding options
•
Remote Access Service
•
Services for Macintosh
Boundary Layers
A
boundary is the unified interface between the functional layers in the Windows NT network architecture model. Creating boundaries as breakpoints in the network layers helps open the system to outside development, making it easier for outside vendors to develop network drivers and services. Because the functionality that must be implemented between the layers is well defined, developers need to program only between the boundary layers instead of going from the top to the bottom. Boundary layers also enable software developed above and below a level to be integrated without rewriting.
There are two significant boundary layers in the Windows NT operating system network architecture: the Network Driver Interface Specification (NDIS) 3.0 boundary layer and TDI boundary layer.
The NDIS 3.0 boundary layer provides the interface to the NDIS wrapper and device drivers.
Figure 1.10 Windows NT boundary layers
Transport Driver Interface
TDI is a common interface for a driver (such as the Windows NT redirector and server) to communicate with the various network transports. This allows redirectors and servers to remain independent of transports. Unlike NDIS, there is no driver for TDI; it is simply a standard for passing messages between two layers in the network architecture.
Network Driver Interface Specification 3.0
In 1989, Microsoft and 3Com jointly developed a specification defining an interface for communication between the MAC sublayer and protocol drivers higher in the OSI model. Network Driver Interface Specification (NDIS) is a standard that allows multiple network adapters and multiple protocols to coexist. NDIS permits the high-level protocol components to be independent of the network interface card by providing a standard interface. The network interface card driver is at the bottom of the network architecture. Because the Windows NT network architecture supports NDIS 3.0, it requires that network adapter-card drivers be written to the NDIS 3.0 specification. NDIS 3.0 allows an unlimited number of network adapter cards in a computer and an unlimited number of protocols that can be bound to a single adapter card.
In Windows NT, NDIS has been implemented in a module called Ndis.sys, which is referred to as the NDIS wrapper.
The NDIS wrapper is a small piece of code surrounding all of the NDIS device drivers. The wrapper provides a uniform interface between protocol drivers and NDIS device drivers, and contains supporting routines that making it easier to develop an NDIS driver.
Figure 1.11 NDIS Wrapper
Previous implementations of NDIS required a protocol manager (PROTMAN) to control access to the network adapter. The primary function of PROTMAN was to control the settings on the network adapter and the bindings to specific protocol stacks. The Windows NT operating system networking architecture does not need a PROTMAN module because adapter settings and bindings are stored in the registry and configured using Control Panel.
Because the NDIS wrapper controls the way protocols communicate with the network adapter card, the protocols communicate with the NDIS wrapper rather than with the network adapter card itself. This is an example of the modularity of the layered model. The network adapter card is independent from the protocols; therefore, a change in protocols does not require changing settings for the network adapter card.
Network Protocols
The Windows NT operating system ships with four network protocols:
•
Data Link Control (DLC)
•
NetBEUI
•
TCP/IP
•
NWLink (IPX/SPX)
Figure 1.12 Windows NT network protocols
Data Link Control
Unlike the other protocols, the Data Link Control (DLC) protocol is not designed to be a primary protocol for network use between personal computers. DLC provides applications with direct access to the data-link layer but is not used by the Windows NT operating system redirector. Since the redirector cannot use DLC, this protocol is not used for normal-session communication between computers running Windows NT Server or Windows NT Workstation.
The DLC protocol is primarily used for two tasks.
•
Accessing IBM mainframes, which usually run 3270 applications.
•
Printing to Hewlett-Packard printers connected directly to the network.
Network-attached printers, such as the HP III, use the DLC protocol because the received frames are easy to take apart and because DLC functionality can easily be coded into read-only memory (ROM).
DLC needs to be installed only on those network machines that perform these two tasks, such as a print server sending data to a network HP printer. Client computers sending print jobs to the network printer do not need the DLC protocol; only the print server communicating directly with the printer needs the DLC protocol installed.
The registry location for the DLC parameters is:
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \DLC
The registry entry for the DLC driver indicates that it is loaded after the kernel has been started (Start 0x1), and it is dependent on having an NDIS group service available. Its linkage shows that it is bound to the network adapter by the appropriate NDIS device driver.
NetBIOS Extended User Interface
IBM introduced NetBIOS Extended User Interface (NetBEUI) in 1985. NetBEUI was developed for small departmental LANs of 20 to 200 computers. It was assumed that these LANs would be connected by gateways to other LAN segments and mainframes.
NetBEUI version 3.0 is included with Windows NT Server and Windows NT Workstation. It features the following advantages.
•
Provides a fast protocol on small LANs
•
Breaks the 254-session barrier of previous versions of NetBEUI
•
Provides much better performance over slow links than previous versions of NetBEUI
•
Is completely self-tuning and has good error protection
•
Uses a small amount of memory
•
Does not require configuring
NetBEUI has two disadvantages.
•
NetBEUI is not routable.
•
NetBEUI performance across WANs is poor.
The registry location for the NetBEUI parameters is:
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \NBF
The NetBEUI registry entry looks like the DLC entry. Like the DLC driver, NetBEUI is dependent on having an available NDIS group service. Also, under the linkage key, NetBEUI is bound to the network adapter entry by way of the NDIS device driver entry.
Strictly speaking, NetBEUI 3.0 is not truly NetBEUI because it is not inherently extending the NetBIOS interface. Instead, its upper-level interface conforms to the TDI. However, NetBEUI 3.0 still uses the NetBIOS Frame Format (NBF) protocol and is completely compatible and interoperable with previous versions of NetBEUI.
Network applications speaking directly to the NetBEUI 3.0 protocol driver now must use TDI commands instead of NetBIOS commands. This is a departure from earlier implementations of NetBEUI on MS-DOS and OS/2, which provided the programming interface as part of the transport's device driver. There is nothing wrong with this, but in the Windows NT operating system implementation, the programming interface (NetBIOS) has been separated from the protocol (NetBEUI) to increase flexibility in the layered architecture. Two points summarize the difference between these two.
•
NetBEUI is a protocol.
•
NetBIOS is a programming interface.
Transmission Control Protocol/Internet Protocol
TCP/IP is an industry-standard suite of protocols designed for WANs. It was developed in 1969, resulting from a Defense Advanced Research Projects Agency (DARPA) research project on network interconnection.
DARPA developed TCP/IP to connect its research networks. This combination of networks continued to grow and now includes many government agencies, universities, and corporations. This global WAN is called the
Internet.
The Windows NT TCP/IP allows users to connect to the Internet and to any machine running TCP/IP and providing TCP/IP services.
Some of the advantages of TCP/IP protocol are that it provides the following functions.
•
Providing connectivity across operating systems and hardware platforms
•
Providing access to the Internet
•
Providing a routable protocol
•
Supporting Simple Network Management Protocol (SNMP)
•
Supporting Dynamic Host Configuration Protocol (DHCP), which provides dynamic IP-address assignments
•
Supporting Windows Internet Name Service (WINS), which provides a dynamic database of IP address-to-NetBIOS name-resolution mappings
The registry location for TCP/IP parameters is:
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip
NWLink (IPX/SPX)
NWLink is an IPX/SPX-compatible protocol for the Windows NT network architecture. It can be used to establish connections between computers running Windows NT Server or Windows NT Workstation and MS-DOS, OS/2, and Microsoft Windows through a variety of communication mechanisms.
NWLink is simply a protocol. By itself, it does not allow a computer running Windows NT Server or Windows NT Workstation to access files or printers shared on a NetWare server, or to act as a file or print server to a NetWare client. To access files or printers on a NetWare server, a redirector must be used, such as the Client Service for NetWare (CSNW) on Windows NT Workstation or the Gateway Service for NetWare (GSNW) on Windows NT Server.
NWLink is useful if there are NetWare client/server applications running that use Sockets or NetBIOS over the IPX/SPX protocol. The client portion can be run on a Windows NT Server or Windows NT Workstation system to access the server portion on a NetWare server, and vice versa.
NWNBLink contains Microsoft enhancements to Novell NetBIOS. The NWNBLink component is used to format NetBIOS-level requests and pass them to the NWLink component for transmission on the network.
The registry location for NWLink parameters is:
HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \NWLINK
Streams
Streams are multiple data channels that allow broader bandwidth for data transfer. There are two reasons for writing a protocol to use the Streams device driver.
•
Streams makes it easier to port existing protocols to the Windows NT operating system.
•
Streams encourages protocols to be organized in a modular, stackable style, thus moving closer to the original vision of the OSI model.
Figure 1.13 Windows NT 3.1 Streams
In Windows NT version 3.1, both TCP/IP and NWLink were surrounded by a Streams device driver. Calls to the TCP/IP or NWLink protocol first passed through the upper layer of the Streams device driver, and then to the NDIS device driver by way ofthe lower layer of the Streams device driver. The streams device driver exposes the TDI interface at its top and the NDIS interface at the bottom. Streams is a significant departure from the way protocols were developed for MS-DOS and OS/2.
Streams has one great disadvantage: overhead. The protocol requires more instructions to pass a request from the TDI through Streams than if Streams were not used. This is why TCP/IP and NWLink do not use Streams in Windows NT version 3.5 or later.
Distributed Processing
A powerful computer can share its processing power, executing tasks on behalf of other computers. Applications that split processing between networked computers are called
distributed applications. Aclient/server application is a distributed application in which processing is divided between a workstation (the client) and a more powerful server. The client portion is sometimes referred to as the front end and the server portion is sometimes referred to as the back end.
The client portion of a client/server application usually consists of just the user interface to the application. It runs on the client workstation and takes a low-to- average amount of processing power. Typically, processing done by the client portion requires a large network bandwidth. For example, the client portion would handle screen graphics, mouse movements, and keystrokes.
The server portion of a client/server application often requires large amounts of data storage, computing power, and specialized hardware. It performs operations that include database lookups, updates, and mainframe data access.
The goal of distributed processing is to move the actual application processing from the client system to a server system with the power to run large applications. During execution, the client portion formats requests and sends them to the server for processing. The server executes the request.
Distributed Component Object Model
In addition to supporting component object model (COM) for interprocess communication on a local computer, Windows NT Server now supports distributed component object model (DCOM). DCOM (or Networked OLE) is a system of software objects designed to be reusable and replaceable. The objects support sets of related functions, such as sorting, random-number generation, and database searches. Each set of functions is called an
interface, and each DCOM object can have multiple interfaces. When applications access an object, they receive an indirect pointer to the interface functions. From then on, the calling application doesn't need to know where the object is or how it does its job.
DCOM allows you to efficiently distribute processes across multiple computers so that the client and server components of an application can be placed in optimal locations on the network. Processing occurs transparently to the user. Thus, the user can access and share information without needing to know where the application components are located. If the client and server components of an application are located on the same computer, DCOM can be used to transfer information between processes. DCOM is platform independent and supports any 32-bit application that is DCOM-aware.
Note Before you can use an application with DCOM, you must use DCOM Configuration to set the application's properties.
Advantages of Using DCOM
DCOM is the preferred method for developers to use in writing client/server applications for Windows NT.
With DCOM, interfaces can be added or upgraded without deleting the old ones, so applications aren't forced to upgrade each time the object changes. Functions are implemented as dynamic-link libraries, so changes in the functions, including new interfaces or the way the function works, can be made without recompiling the applications that call them.
Windows NT 4.0 supports DCOM by making the implementation of application pointers transparent to the application and the object. Only the operating system needs to know if the function called is handled in the same process or across the network. This frees the application from concerns with local or remote procedure calls. Administrators can choose to run DCOM applications on local or remote computers, and can change the configuration for efficient load balancing.
For example, suppose your company's payroll department uses an application with DCOM to print paychecks. When a payroll employee runs a DCOM-enabled client application on a desktop, the application starts a business-rules server. Then, the server application connects to a database server and retrieves employee records, such as salary information. The business-rules server then transforms the payroll information into the final output and returns it to the client to print.
Your application may support its own set of DCOM features. For more information about configuring your application to use DCOM, see your application's documentation.
DCOM builds upon remote procedure call (RPC) technology by providing a more scalable, easier-to-use mechanism for integrating distributed applications on a network. A distributed application consists of multiple processes that cooperate to accomplish a single task. Unlike other interprocess communication (IPC) mechanisms, DCOM gives you a high degree of control over security features, such as permissions and domain authentication. It can also be used to launch applications on other computers or to integrate web-browser applications that run on the ActiveX™ platform.
Microsoft Visual Basic®, Enterprise Edition customers who are currently using Remote Automation can easily migrate their existing applications to use DCOM. For more information, see your Visual Basic documentation or visit the Visual Basic web site at
www.microsoft.com/vbasic.
Setting Security on DCOM Applications
The Windows NT 4.0 security model is easily extended to DCOM objects. Administrators set permissions on DCOM applications and can vary those permissions for local and remote execution.
Once a DCOM-enabled application is installed, you can use DCOM Configuration (in Control Panel) for the following purposes.
•
To disable DCOM so that it can't be used for the computer or the application.
•
To set the location of the application.
•
To set permissions on the server application by specifying which user accounts can or cannot access or start it. You can grant permissions that apply to all applications installed on the computer or to only a particular application.
•
To set the user account (or identity) that will be used to run the server application. The client application uses this account to start processes and access resources on other computers in the domain. If the server application is installed as a service, you can run the application using the built-in System account or a Windows NT Server service account that you have created.
•
To control the level of security (for example, packet encryption) for connections between applications.
The computers running the client application and the server application must both be configured for DCOM. On the computer running as a client, you must specify the location of the server application that will be accessed or started. For the computer running the server application, you must specify the user account that will have permission to access or start the application, and the user account that will be used to run the application.
Interprocess Communication Mechanisms for Distributed Processing
The connection between the client and server portions of distributed applications must allow data to flow in both directions. There are a number of ways to establish this connection. The Windows NT operating system provides seven different Interprocess Communication (IPC) mechanisms.
•
Named Pipes
•
Mailslots
•
NetBIOS
•
Windows Sockets
•
Remote Procedure Calls (RPCs)
•
Network Dynamic Data Exchange (NetDDE)
•
Server Message Blocks (SMBs)
•
Distributed Component Object Model (DCOM)
Named Pipes and Mailslots
A pipe is a portion of memory that can be used by one process to pass information to another. A pipe connects two processes so that the output of one can be used as input to the other.
Named pipes and mailslots are actually written as file system drivers, so implementation of named pipes and mailslots differs from implementation of other IPC mechanisms. There are entries in the registry for NPFS (Named Pipe File System) and MSFS (Mailslot File System). As file systems, they share common functionality, such as security, with the other file systems. Local processes can also use named pipes and mailslots. As with all of the file systems, remote access to named pipes and mailslots is accomplished through the redirector.
Named pipes provide connection-oriented messaging. Named pipes are based on OS/2 API calls, which have been ported into the Win32 base API set. Additional asynchronous support has been added to named pipes to make support of client/server applications easier.
In addition to the APIs ported from OS/2, the Windows NT operating system provides special APIs that increase security for named pipes. Using a feature called
impersonation, the server can change its security identity to that of the client at the other end of the message. A server typically has more permissions to access databases on the server than the client requesting services has. When the request is delivered to the server through a named pipe, the server changes its security identity to the security identity of the client. This limits the server to only those permissions granted to the client rather than its own permissions, thus increasing the security of named pipes.
The mailslot implementation in the Windows NT operating system is a subset of the Microsoft OS/2 LAN Manager implementation. The Windows NT operating system implements only second-class mailslots, not first-class mailslots. Second-class mailslots provide connectionless messaging for broadcast messages. Delivery of the message is not guaranteed, although the delivery rate on most networks is quite high. Connectionless messaging is most useful for identifying other computers or services on a network, such as the Computer Browser service offered in the Windows NT operating system.
For a description of connectionless messaging, see "Data Transfer Modes," earlier in this chapter.
NetBIOS
NetBIOS is a standard programming interface in the personal-computing environment for developing client/server applications. NetBIOS has been used as an IPC mechanism since the introduction of the interface in the early 1980s.
A NetBIOS client/server application can communicate over various protocols:
•
NetBEUI Frame protocol (NBF).
•
NWLink NetBIOS (NWNBLink).
•
NetBIOS over TCP/IP (NetBT). NetBT provides RFC 1001/1002 NetBIOS support for the TCP/IP protocol stack.
From a programming perspective, higher-level IPC mechanisms, such as named pipes and RPC, have superior flexibility and portability.
NetBIOS uses the following components.
•
Netapi32.dll, which shares the address space of the NetBIOS user-mode application. (However, Netapi32.dll is used for more than NetBIOS requests.)
•
NetBIOS emulator, which provides the NetBIOS mapping layer between NetBIOS applications and the TDI-compliant protocols.
Figure 1.14 NetBIOS programming interface
MS-DOS and NetBIOS applications are hard-coded to use a specific LANA number for communicating on the network. You can assign a LANA number to each network route. The network route consists of the protocol driver and the network adapter that will be used for NetBIOS commands sent to its assigned LANA number.
To assign a LANA number to a network route
1.
Click
Start, point to
Settings, and click
Control Panel.
2.
Double-click
Network.
3.
Click the
Services tab.
4.
Click
NetBIOS Interface, and then click
Properties.
The
NetBIOS Configuration dialog box appears.
5.
Click the number you want under
Lana Number, and then click
Edit.
6.
Type a new number, and click
OK.
Windows Sockets
The Windows Sockets API provides a standard interface to protocols with different addressing schemes. The Sockets interface was developed at the University of California, Berkeley, in the early 1980s. The Windows Sockets API was developed to migrate the Sockets interface into the Windows and Windows NT environments. Windows Sockets was also developed to help standardize an API for all operating system platforms. Windows Sockets is supported on the following protocols.
•
TCP/IP
•
NWLink (IPX/SPX)
Figure 1.15 Windows Sockets programming interface
Windows Sockets consists of the following items.
•
Wsock32.dll, which shares the address space of the Windows Sockets user-mode application.
•
Windows Sockets emulator, which provides the Windows Sockets mapping layer between the Windows Sockets applications and the TDI-compliant protocols.
Remote Procedure Call
Much of the original work on Remote Procedure Call (RPC) was initiated at Sun Microsystems. This work has been carried forward by the Open Software Foundation (OSF) as part of their Distributed Computing Environment (DCE). The Microsoft RPC implementation is compatible with the OSF/DCE standard RPC.
It is important to note that it is
compatible but not
compliant. In this situation, compliance implies that you started with the OSF source code and worked forward. For a number of reasons, Microsoft developed RPC from the ground up. The RPC mechanism is completely compatible with other DCE - based RPC systems, such as the ones for HP and IBM/AIX systems, and will interoperate with them.
The Microsoft RPC mechanism is unique in that it uses the other IPC mechanisms to establish communications between the client and the server. RPC can use the following to communicate with remote systems:
•
Named pipes
•
NetBIOS
•
Windows Sockets
If the client and server portions of the application are on the same machine, local procedure calls (LPCs) can be used to transfer information between processes. This makes RPC the most flexible and portable of the IPC choices available.
RPC is based on the concepts used for creating structured programs, which can be viewed as having a "backbone" to which a series of "ribs" can be attached. The backbone is the mainstream logic of the program, which should rarely change. The ribs are the procedures that the backbone calls on to do work or perform functions. In traditional programs, these ribs were statically linked to the backbone and stored in the same executable.
Windows and OS/2 use data-link libraries (DLLs). With DLLs, the procedure code and the backbone code are in different pieces. This enables the DLL to be modified or updated without changing or redistributing the backbone portion.
RPC takes the concept one step further and places the backbone and the ribs on different computers. This raises many issues, such as data formatting, integer-byte ordering, locating which server contains the function, and determining which communication mechanism to use.
RPC is the developer's preferred method for writing client/server applications for Windows NT. The components necessary to use a remote procedure call are the following items.
•
Remote Procedure Stub (Proc Stub), which packages remote procedure calls to be sent to the server by means of the RPC run time.
•
RPC Run Time (RPC RT), which is responsible for communications between the local and remote computer, including the passing of parameters.
•
Application Stub (APP Stub), which accepts RPC requests from RPC RT, unwraps the package, and makes the appropriate call to the remote procedure.
•
Remote Procedure, which is the actual procedure that is called by the network.
Client applications are developed with a specially compiled "stub" library. The client application "thinks" it will call its own subroutines. In reality, these stubs will transfer the data and the function to the RPC RT module. This module will be responsible for finding the server that can satisfy the RPC command. Once found, the function and data will be sent to the server, where they are picked up by the RPC RT component on the server. The server piece then loads the library needed for the function, builds the appropriate data structure, and calls the function.
The function interprets the call as coming from the client application. When the function is completed, any return values will be collected, formatted, and sent back to the client through the RPC RT. When the function returns to the client application, it will have the appropriate returned data or an indication that the function failed.
Figure 1.16 How RPC calls operate
Network Dynamic Data Exchange
Network Dynamic Data Exchange (NetDDE) is an extension of the Dynamic Data Exchange (DDE) protocol that has been in use since Windows version 2.
x. NetDDE enables users to use DDE over a NetBIOS-compatible network. To understand NetDDE, you need to know something about DDE.
DDE is a protocol that allows applications to exchange data. To perform such an exchange, the two participating applications must first engage in a DDE conversation. The application that initiates the DDE conversation is the DDE client application, and the application that responds to the client request is the DDE server application.
A single application can be simultaneously engaged in multiple DDE conversations, acting as the DDE client application in some DDE conversations and as the DDE server application in others. This allows a user to set up a DDE link between applications and have one of the applications automatically update another.
Figure 1.17 NetDDE
NetDDE extends all of the DDE capabilities so that they can be used across the network, using the NetBIOS emulator. This enables applications on two or more workstations to dynamically share information. NetDDE is not a special form of DDE but rather a service that examines the information contained in a DDE conversation and looks for a special application name. Implementing NetDDE in this manner allows any DDE application to take advantage of NetDDE without modification.
The NetDDE service examines DDE requests, looking for the use of a special application name reserved by NetDDE, which is preceded by the name of the remote system. The reserved application name is NDDE$; therefore, NetDDE is looking for DDE requests that use an application name in the following form: \\<
servername>\ndde$.
Before a user can connect to a printer or directory from a remote location, the printer or directory must be shared. Similarly, a NetDDE share must be created on a computer before an application on that computer can use NetDDE to communicate with the application on another computer. NetDDE-aware applications, such as Chat, automatically create a NetDDE share for themselves during installation. For other applications, a NetDDE share can be created with ClipBook Viewer, and data can then be exchanged through the ClipBoard. In addition, Windows NT includes the DDE Share utility (Ddeshare.exe), which can be used to set up a NetDDE share so that applications can directly exchange data.
NetDDE shares are defined in the registry. They are accessed by communicating with the Network DDE Service Data Manager (DSDM), which is the Windows NT operating system service that supports the rest of NetDDE.
Because NetDDE is simply an extension of DDE, the same APIs used to establish a DDE conversation are used to establish NetDDE conversations.
In Windows NT 3.1, the NetDDE services automatically load at system startup. In Windows NT 3.5 and later, the default startup type for NetDDE is manual, which improves startup time. The startup type for the NetDDE services can be configured through Control Panel.
Server Message Blocks
The Server Message Blocks (SMB) protocol, developed jointly by Microsoft, Intel, and IBM, defines a series of commands used to pass information between networked computers. The redirector packages network-control-block (NCB) requests meant for remote computers in a SMB structure. SMBs can be sent over the network to remote devices. The redirector also uses SMBs to make requests to the protocol stack of the local computer, such as "Create a session with the file server."
SMB uses four message types, which are listed below.
•
Session control messages, which consist of commands that start and end a redirector connection to a shared resource at the server.
•
File messages, which are used by the redirector to gain access to files at the server.
•
Printer messages, which are used by the redirector to send data to a print queue at a server and to get status information about the print queue.
•
Message messages, which allow an application to exchange messages with another workstation.
The provider DLL listens for SMB messages destined for it and removes the data portion of the SMB request so that it can be processed by a local device.
SMBs provide interoperability between different versions of the Microsoft family of networking products and other networks that use SMBs, including those on the following list.
•
MS® OS/2 LAN Manager
•
Microsoft Windows for Workgroups
•
IBM LAN Server
•
MS-DOS LAN Manager
•
DEC PATHWORKS
•
Microsoft LAN Manager for UNIX
•
3Com 3+Open
•
MS-Net
Network Resource Access
Applications reside above the redirector and server services in user mode. Like all other layers in the Windows NT networking architecture, there is a unified interface for accessing network resources, which is independent of any redirectors installed on the system. Access to resources is provided through one of two components: the Multiple Universal Naming Convention Provider (MUP) and the Multi-Provider Router (MPR).
Multiple Universal Naming Convention Provider
When applications make I/O calls containing Universal Naming Code (UNC) names, these requests are passed to the Multiple Universal Naming Convention Provider (MUP). MUP selects the appropriate UNC provider (redirector) to handle the I/O request.
Universal Naming Convention Names
UNC is a naming convention for describing network servers and the share points on those servers. UNC names start with two backslashes followed by the server name. All other fields in the name are separated by a single backslash. A typical UNC name would appear as: \\server\share\subdirectory\filename.
Not all of the components of the UNC name need to be present with each command; only the share component is required. For example, the command
dir\\servername\sharename can be used to obtain a directory listing of the root of the specified share.
Why MUP?
One of the design goals of the Windows NT networking environment is to provide a platform upon which others can build. MUP is a vital part of allowing multiple redirectors to coexist in the computer. MUP frees applications from maintaining their own UNC-provider listings.
How MUP Works
MUP is actually a driver, unlike the TDI interface, which merely defines the way a component on one layer communicates with a component on another layer. MUP also has defined paths to UNC providers (redirectors).
I/O requests from applications that contain UNC names are received by the I/O Manager, which in turn passes the requests to MUP. If MUP has not seen the UNC name during the previous 15 minutes, MUP will send the name to each of the UNC providers registered with it. MUP is a prerequisite of the Workstation service.
Figure 1.18 Multiple Universal Naming Convention Provider
When a request containing a UNC name is received by MUP, it checks with each redirector to find out which one can process the request. MUP looks for the redirector with the highest registered-priority response that claims it can establish a connection to the UNC. This connection remains as long as there is activity. If there has been no request for 15 minutes on the UNC name, then MUP once again negotiates to find an appropriate redirector.
Multi-provider Router
Not all programs use UNC names in their I/O requests. Some applications use WNet APIs, which are the Win32 network APIs. The Multi-Provider Router (MPR) was created to support these applications.
MPR is similar to MUP. MPR receives WNet commands, determines the appropriate redirector, and passes the command to that redirector. Because different network vendors use different interfaces for communicating with their redirector, there is a series of provider DLLs between MPR and the redirectors. The provider DLLs expose a standard interface so that MPR can communicate with them. The DLLs "know" how to take the request from MPR and communicate it to their corresponding redirector.
Figure 1.19 Multi-provider Router
The provider DLLs are supplied by the network-redirector vendor and should automatically be installed when the redirector is installed.
The Workstation Service
All user-mode requests go through the Workstation service. This service consists of two components.
•
The user-mode interface, which resides in Lmsvcs.exe in Windows NT 3.1 and Services.exe in Windows NT 3.5 and later.
•
The redirector (Rdr.sys), which is a file-system driver that interacts with the lower-level network drivers by means of the TDI interface.
The Workstation service receives the user request, and passes it to the kernel-mode redirector.
Figure 1.20 Workstation Service
Windows NT Redirector
The redirector (RDR) is a component that resides above TDI and through which one computer gains access to another computer. The Windows NT operating system redirector allows connection to Windows for Workgroups, LAN Manager, LAN Server, and other MS-Net-based servers. The redirector communicates to the protocols by means of the TDI interface.
The redirector is implemented as a Windows NT file system driver. Implementing a redirector as a file system has several benefits, which are listed below.
•
It allows applications to call a single API (the Windows NT I/O API) to access files on local and remote computers. From the I/O Manager perspective, there is no difference between accessing files stored on a remote computer on the network and accessing those stored locally on a hard disk.
•
It runs in kernel mode and can directly call other drivers and other kernel-mode components, such as Cache Manager. This improves the performance of the redirector.
•
It can be dynamically loaded and unloaded, like any other file-system driver.
•
It can easily coexist with other redirectors.
Figure 1.21 Windows NT redirector
Interoperating with Other Networks
Besides allowing connections to LAN Manager, LAN Server, and MS-Net servers, the Windows NT redirector can coexist with redirectors for other networks, such as Novell NetWare and Banyan VINES.
While Windows NT includes integrated networking, its open design provides transparent access to other networks. For example, a computer running Windows NT Server can concurrently access files stored on Windows NT and NetWare servers.
Providers and the Provider-interface Layer
For each additional type of network, such as NetWare or VINES, you must install a component called a
provider. The provider is the component that allows a computer running Windows NT Server or Windows NT Workstation to communicate with the network. The Windows NT operating system includes two providers; Client Services for NetWare and Gateway Services for NetWare.
Client Services for NetWare is included with Windows NT Workstation and allows a computer running Windows NT Workstation to connect as a client to the NetWare network. The Gateway service, included with Windows NT Server, allows a computer running Windows NT Server to connect as a client to the NetWare network. Other provider DLLs are supplied by the appropriate network vendors.
Accessing a Remote File
When a process on a Windows NT computer tries to open a file that resides on a remote computer, the following steps occur.
First, the process calls the I/O Manager to request that the file be opened.
Then, the I/O Manager recognizes that the request is for a file on a remote computer, and passes the request to the redirector file-system driver.
Finally, the redirector passes the request to lower-level network drivers, which transmit it to the remote server for processing.
Workstation Service Dependencies
Configuration requirements for loading the Workstation service include:
•
A protocol that exposes the TDI interface must be started.
•
The MUP driver must be started.
The Server Service
Windows NT includes a second component, called the Server service. Like the redirector, the Server service sits above TDI, is implemented as a file system driver, and directly interacts with various other file-system drivers to satisfy I/O requests, such as reading or writing to a file.
The Server service supplies the connections requested by client-side redirectors and provides them with access to the resources they request.
When the Server service receives a request from a remote computer asking to read a file that resides on the local hard drive, the following steps occur.
•
The low-level network drivers receive the request and pass it to the server driver (SRV).
•
The Server service passes a read-file request to the appropriate local file-system driver.
•
The local file-system driver calls lower-level, disk-device drivers to access the file.
•
The data is passed back to the local file-system driver.
•
The local file-system driver passes the data back to the Server service.
•
The Server service passes the data to the lower-level network drivers for transmission back to the client computer.
Figure 1.22 Server Service
Like the Workstation service, the Server service is composed of two parts.
•
Server, a service that runs in the Services.exe, which is the Service Control Manager, where all services start. Unlike the Workstation service, the Server service is not dependent on the MUP service because the server is not a UNC provider. It does not attempt to connect to other computers, but other computers connect to it.
•
Srv.sys, a file system driver that handles the interaction with the lower levels and directly interacts with various file system devices to satisfy command requests, such as file read and write.
Binding Options
Earlier in this chapter, we discussed how the Windows NT network architecture consists of a series of layers and how components in each layer perform specific functions for the layers above and below it. The bottom of the network architecture ends at the network adapter card, which moves information between computers that are part of the network.
Figure 1.23 Network protocol bindings
The linking of network components on different levels to enable communication between those components is called
binding. A network component can be bound to one or more network components above or below it. The services that each component provides can be shared by all the components bound to it.
When adding network software, Windows NT automatically binds all dependent components accordingly.
In the Network window, the
Bindings tab displays the bindings of the installed network components, from the upper-layer services and protocols to the lowest layer of network adapter drivers. Bindings can be enabled and disabled, based on the use of the network components installed on the system.
Figure 1.24 The Settings tab of the Network window
Bindings can be ordered or sequenced to optimize the system's use of the network. For example, if NetBEUI and TCP/IP are installed on a computer, and if most of servers that the computer connects to are running only TCP/IP, the Workstation bindings should be examined. The administrator of this computer would want to make sure that the Workstation is bound to TCP/IP first and that NetBEUI is at the bottom of the list.
In Windows NT 3.1, the redirector uses the following method to establish a connection.
•
First, the redirector submits the connect request to the first protocol driver in the bindings order and waits for that protocol driver to complete the request and return.
•
If the first protocol driver's return indicates that it could not connect to the specified server, then the redirector submits the connect request to the second protocol driver in the bindings order.
•
This continues down the bindings order until a protocol-driver return indicates that the connection was successful or until all protocol drivers have been tried and have failed.
In Windows NT 3.5 and later, the redirector uses the following method to establish a connection.
•
The redirector simultaneously submits the connect request to all protocol drivers.
•
When one of the protocol drivers successfully completes the request, the redirector waits until all higher-priority protocol drivers, if there are any, have been returned. (The priority is based on the bindings order.)
•
The redirector then proceeds to use the highest-priority protocol driver that returned with success status, and it disconnects all connections that may have been established through lower-priority protocol drivers.
Remote Access Service
The Windows NT Workstation and Windows NT Server RAS connects remote or mobile workers to corporate networks. Optimized for client/server computing, RAS is implemented primarily as a software solution, and is available on all Microsoft operating systems.
The distinction between RAS and remote control solutions (such as Cubix and pcANYWHERE) are important:
•
RAS is a software-based multi-protocol router; remote control solutions work by sharing screen, keyboard, and mouse over the remote link.
•
In a remote control solution, users share a CPU or multiple CPUs on the server. The RAS server's CPU is dedicated to communications, not to running applications.
Point-to-Point Protocol
The Windows NT operating system supports the Point-to-Point Protocol (PPP) in RAS. PPP is a set of industry-standard framing and authentication protocols. PPP negotiates configuration parameters for multiple layers of the OSI model.
PPP support in Windows NT 3.5 and later (and Windows 95) means that computers running Windows can dial into remote networks through any server that complies with the PPP standard. PPP compliance enables a Windows NT Server to receive calls from other vendors' remote-access software and to provide network access to them.
The PPP architecture also enables clients to load any combination of IPX, TCP/IP, and NetBEUI. Applications written to the Windows Sockets, NetBIOS, or IPX interfaces can now be run on a remote computer running Windows NT Workstation. The following figure illustrates the PPP architecture of RAS.
Figure 1.25 Point-to-Point Protocol
RAS Connection Sequence
The RAS connection sequence is key to understanding the PPP protocol. Upon connecting to a remote computer, the PPP negotiation begins.
•
First, framing rules are established between the remote computer and server. This allows continued communication (frame transfer) to occur.
•
Next, the RAS server uses the PPP authentication protocols (PAP, CHAP, SPAP) to authenticate the remote user. The protocols invoked depend on the security configurations of the remote client and server.
•
Once authenticated, the Network Control Protocols (NCPs) are used to enable and configure the server for the LAN protocol that will be used on the remote client.
When the PPP connection sequence is successfully completed, the remote client and RAS server can begin to transfer data using any supported protocol, such as Windows Sockets, RPC, or NetBIOS. The following illustration shows where the PPP protocol is on the OSI model.
Figure 1.26 PPP within the OI model
If a remote client is configured to use the NetBIOS Gateway or Serial Line Internet Protocol (SLIP), this sequence is invalid.
Point-to-Point Tunneling Protocol
A RAS server is usually connected to a PSTN, ISDN, or X.25 network, allowing remote users to access a server through these networks. RAS now allows remote users access through the Internet by using the new Point-to-Point Tunneling Protocol (PPTP).
PPTP is a new networking technology that supports multiprotocol virtual private networks (VPNs), enabling remote users to access corporate networks securely across the Internet by dialing into an Internet Service Provider (ISP) or by connecting directly to the Internet. For more information, see the
Microsoft Windows NT Server Networking Supplement, Chapter 11, "Point-to-Point Tunneling Protocol."
NetBIOS Gateway
Windows NT continues to support NetBIOS gateways, the architecture used in previous versions of the Windows NT operating system and LAN Manager. Remote users connect using NetBEUI, and the RAS server translates packets to IPX or TCP/IP, if necessary. This enables users to share network resources in a multiprotocol LAN, but prevents them from running applications that rely on IPX or TCP/IP on the client. The NetBIOS gateway is used by default when remote clients use NetBEUI. The following illustration shows the NetBIOS gateway architecture of RAS.
Figure 1.27 NetBIOS gateway architecture of RAS
An example of the NetBIOS gateway capability is remote network access for Lotus Notes users. While Lotus Notes does offer dial-up connectivity, dial-up is limited to the Notes application. RAS complements this connectivity by providing a low-cost, high-performance, remote-network connection for Notes users, which connects Notes and offers file and print services with access to other network resources.
Serial Line Internet Protocol
SLIP is an older communications standard found in UNIX environments. SLIP does not provide the automatic negotiation of network configuration and encrypted authentication that PPP can provide. SLIP requires user intervention. Windows NT RAS can be configured as a SLIP client, enabling users to dial into an existing SLIP server. RAS does not provide a SLIP server in Windows NT Server.
For more information about RAS issues, see the Rasphone.hlp online Help file on the Windows NT distribution disks (or, if RAS has been installed, see
systemroot\System32).
Services for Macintosh
Through Windows NT Services for Macintosh, Macintosh users can connect to a Windows NT server in the same way they would connect to an AppleShare server. Windows NT Services for Macintosh will support an unlimited number of simultaneous AFP connections to a Windows NT server, and Macintosh sessions will be integrated with Windows NT sessions. The per-session memory overhead is approximately 15K.
Existing versions of LAN Manager Services for the Macintosh can be easily upgraded to Windows NT Services for Macintosh. OS/2-based volumes that already exist are converted with permissions intact. Graphical installation, administration, and configuration utilities are integrated with existing Windows NT administration tools. Windows NT Services for Macintosh requires System 6.0.7 or higher and is AFP 2.1-compliant; however, AFP 2.0 clients are also supported. AFP 2.1 compliance provides support for logon messages and server messages.
Support for Macintosh networking is built into the core operating system for Windows NT Server. Windows NT Services for Macintosh includes a full AFP 2.0 file server. All Macintosh file system attributes, such as resource data forks and 32-bit directory IDs, are supported. As a file server, all filenames, icons, and access permissions are intelligently managed for different networks. For example, a Word for Windows file will appear on the Macintosh with the correct Word for Macintosh icons. These applications can also be launched from the File Server as Macintosh applications. When files are deleted, no orphaned resource forks will be left to be cleaned up.
Windows NT Services for Macintosh fully supports and complies with Windows NT security. It presents the AFP security model to Macintosh users and allows them to access files on volumes that reside on CD-ROM or other read-only media. The AFP server also supports both cleartext and encrypted passwords at logon time. The administrator has the option to configure the server not to accept cleartext passwords.
Services for Macintosh can be administered from Control Panel and can be started transparently if the administrator has configured the server to use this facility.
Macintosh-accessible volumes can be created in My Computer. Services for Macintosh automatically creates a Public Files volume at installation time. Windows NT file and directory permissions are automatically translated into corresponding Macintosh permissions.
Windows NT Services for Macintosh has the same functionality as the LAN Manager Services for Macintosh 1.0 MacPrint. Administration and configuration are also easier. There is a user interface for publishing a print queue on AppleTalk and a user interface for choosing an AppleTalk printer as a destination device. The Windows NT print subsystem handles AppleTalk despooling errors, and uses the built-in printer support in Windows NT. (The PPD file scheme of Macintosh Services 1.0 is not used.) Services for Macintosh also has a PostScript-compatible engine that allows Macintosh computers to print to any Windows NT printer as if they were printing to a LaserWriter.
Test
