|
|
|
Managing Multivendor Networks
  
- 9 -
PC LAN Network Operating Systems
As discussed in Chapter 8, "Services," PC LANs rely on a robust set
of services delivered to PC clients by designated server systems. Originally, PC
LAN servers only provided simple file and print services, but over time the role
of a PC LAN server has expanded to include application serving, database support,
transaction processing, and a variety of other client/server-related functions. In
many ways, the growing and expanding role of the PC LAN server is challenging the
traditional services offered by commercial midrange and mainframe computers.
Although a variety of vendors competed for the fledgling PC LAN market in the
1980s, one company managed to obtain the lion's share of the market--that company
was Novell. Novell's product, NetWare, ran on a dedicated PC and provided simple
file and print services to other PCs in the network. NetWare became widely popular
largely because it was one of the few products on the market that enabled you to
use whatever type of LAN you preferred--you could implement NetWare over ARCnet,
Ethernet, or Token Ring. Most of the other contemporary PC LAN products were tied
to specific LAN types or specific LAN adapters.
NetWare set the stage for the emerging PC LAN market by defining the capabilities
consumers expected out of a file and print server. Of course, no leading product
can stay unchallenged for long, and Novell's NetWare soon faced serious competition
from products offered by Banyan Systems (VINES), IBM (LAN Server and then OS/2),
and Microsoft (LAN Manager, Windows for Workgroups, Windows 95, and Windows NT).
The following is a quick overview of these four companies and their PC LAN products.
- Novell. As the market leader, Novell set the stage for a long line of
PC LAN innovations that extend well beyond simple file and print services. Novell
designed the NetWare Load Module (NLM) to enable third-party companies to
write server-side NetWare applications and enterprise-oriented features, such as
fault tolerance and data recovery. In terms of scalability, Novell extended the power
and performance of NetWare by allowing other companies to port NetWare from its Intel-only
origin to high-end RISC systems, such as the HP9000. At the network level, the routing
capabilities and simple client configuration of Novell's IPX protocol suite enables
NetWare customers to easily construct networks of any size. Novell has further reinforced
the ease-of-installation and ease-of-maintenance of NetWare with the release of NetWare
Directory Services (NDS), a global directory structure for all NetWare resources.
- Banyan Systems. Banyan Systems' VINES (VIrtual NEtwork Software)provides
file and print serving services similar to NetWare, but VINES runs with existing
network protocols, such as TCP/IP, SNA, and others. More significantly, VINES was
the first PC LAN product to support a network directory service, which Banyan named
StreetTalk. StreetTalk presents a single directory that encompasses multiple
servers and allows users to login only once to access multiple servers. Of course,
Novell later added its own network directory service in version 4.1 of NetWare, and
other network operating systems vendors are following suit. Banyan is, however, unbundling
StreetTalk, and offering it for other platforms, such as Windows NT.
- IBM. IBM's original PC LAN product was the LAN Server, a dedicated
server product that shares the same protocol suite (NetBIOS/NetBEUI) and same overall
architecture as Microsoft's LAN Manager product. This should not be a big surprise
because IBM was one of the core developers of the NetBIOS/NetBEUI protocol suite
and the Server Message Block (SMB) architecture used by IBM, Microsoft, and others.
IBM's DOS -based LAN Server technology was then integrated into it's OS/2
server product. OS/2-based file and print servers have achieved a reputation for
stability and reli- ability; however, OS/2 servers tend to be implemented in sites
that have other IBM equipment--AS/400 and mainframes in particular.
- Microsoft. Microsoft acquired most of its networking technology from 3Com
Corporation. Microsoft incorporated the 3Com technology in its main product lines,
starting with LAN Manager, a dedicated file and print server similar to IBM's
LAN Server offering. Microsoft then went on to extend its networking technology into
workgroup environments with the release of Windows for Workgroups and Windows
95. None of these Microsoft products offered the stability or performance of
a dedicated Novell NetWare server--but this changed with the advent of Windows
NT Server. Windows NT Server is an enterprise-oriented product that can compete
head-to-head with NetWare. Windows NT Server also offers additional features and
value--most notably, the capability to run on a wide range of platforms, fully integrated
support for TCP/IP, and support for a range of software products that enable an NT
Server to function as a full-blown application server.
The PC LAN products offered by all four of these vendors (Novell, Banyan, IBM,
and Microsoft) remain in use today, but two specific products are now competing to
dominate the modern market: Novell's NetWare and Microsoft's Windows NT Server. With
this in mind, the remainder of this chapter will focus on NetWare and Windows NT
Server.
Novell NetWare
As discussed previously, Novell pioneered the PC LAN network operating system
in the PC market. From a technology perspective, however, Novell offered few true
innovations in the area of file and print sharing--most of the concepts Novell implemented
were borrowed from other computer markets. For example, if you look closely you can
see that the original NetWare implementation bears a striking resemblance to Sun's
NFS implementation.
Although you can find fault with Novell's lack of technical innovation in its
early days, you certainly cannot fault Novell's marketing expertise. In the early
days of PC LANs, a number of companies--some big, some small--rushed products to
market to claim space in the exploding market. In all fairness, many of these products
offered technical features and functions superior to NetWare; however, none of the
companies behind those products could match Novell's marketing effort. Novell took
a solid, but hardly best-of-breed product, and leveraged it into a leadership position
through salesmanship and marketing savvy.
Of course, after Novell gained control of the market, they made major develop
investments in NetWare to shore up some of the technical inadequacies and insure
it's longevity in the market. One of the key early developments was the release of
a System Fault Tolerance (SFT) version of NetWare that addressed the data
protection/data recovery demands of large businesses.
Another early criticism of NetWare was that it was a closed operating system--you
had to run NetWare in a dedicated Intel-based system. Novell addressed this complaint
two ways. First, Novell licensed other companies to port NetWare to non-Intel systems,
such as high-performance UNIX systems. These systems were quite capable of running
both NetWare and other business applications concurrently. Second, Novell developed
an application environ-ment inside the NetWare server that permitted third-party
companies to write server-side programs. These programs are referred to as NetWare
Load Modules (NLM) and can handle system-oriented functions, such as tape backup
or application-oriented functions. When used in an application capacity, the server-side
component is typically part of a larger, client/server application.
Like any large, prosperous, and fast-growing company, some of Novell's new products
and new ideas were less than successful. For example, back in the early days of PCs,
when PC hardware was still quite expensive, customers demanded a non-dedicated version
of NetWare so they could also use the server system as a desktop system. Although
Novell did, in fact, come out with a non-dedicated version of NetWare, the implementation
was very awkward and desktop performance was so unpredictable that the product was
impractical to use in most environments.
Novell also proved itself capable of making mistakes on an even grander scale.
At one point Novell went through a phase of acquisition-mania, purchasing a broad
set of companies and products that had nothing to do with NetWare. The intent of
these acquisitions was for Novell to broaden its base beyond NetWare and to enter
the highly competitive (and lucrative) application suite market. During this phase,
Novell purchased high-profile products such as WordPerfect and Quattro Pro.
In addition to acquiring application-oriented products, Novell also acquired a
full-blown implementation of UNIX that it renamed UnixWare. At the time, Novell's
plan was to create a "SuperNOS" by merging NetWare and UnixWare. This SuperNOS
would enable Novell to better compete with the emerging Windows NT product as well
as with the ever-popular UNIX operating system.
Unfortunately for Novell, neither the application suite nor the SuperNOS strategy
panned out--Novell succeeded only in wasting millions of dollars and years of research.
Worse, Novell's lack of focus during this phase enabled Windows NT to penetrate deep
into Novell's file and print server market.
Since that time, Novell has divested itself of both the application and UNIX products
and has recommitted itself to enhancing NetWare on several fronts. On one front,
Novell has launched a Smart Global Network initiative. Under this initiative NetWare
services will be extended to the Internet and to other types of networks so NetWare
can become the central focus of networking in a heterogeneous environment. Additionally,
Novell's Net2000 initiative is targeted to establish an open set of APIs that will
permit users to access network services from non-NetWare platforms and help ease
the task of building distributed applications.
Novell has clearly realized that it is becoming rare for an enterprise to use
a single server operating system. With this in mind, Novell plans to integrate Microsoft,
HP, IBM, Sun, and SCO server platforms by making them all manageable via Novell's
NetWare Directory Services (NDS). NDS, introduced in NetWare 4.1, is a global directory
service that provides an organized, hierarchical structure for the administration
and management of network resources (in other words, users, file servers, shared
printers, and so on).
NDS offers a significant advantage over the older NetWare bindery. Under NDS,
the entire network appears to the end user as a single entity, and permits a single
log on to access all servers and shared network resources. Because the NDS structure
is replicated across servers, there is no single point of failure. The NDS naming
hierarchy can contain up to 15 levels of names (StreetTalk offers only a three-level
naming hierarchy). This allows for a great deal of flexibility, but also raises the
potential of creating overly complex or difficult-to-use names for network resources.
In a very real sense, NDS has become Novell's key competitive advantage in the PC
LAN market.
Integrating NDS
Rather than limiting NDS to a NetWare-only environment, Novell is extending NDS to
other environments. For example, Novell is working with HP to join DCE software with
NDS in a future 64-bit UNIX release. Novell is also collaborating with SCO so that
it can merge NDS with the 32-bit SCO UNIX systems. Similar plans are underway for
integrating NDS with other vendor operating systems, as well as for releasing NDS
client software for a variety of desktop operating systems.
Finally, Novell is also improving NetWare's position in large enterprise environments.
In large environments, NetWare worked well as file and print servers, but did not
fare well as database or messaging servers. To address this limitation, Novell has
introduced NetWare Symmetrical Multi-Processing (SMP) 4.1, which enables NetWare
to take advantage of multiple processor hardware platforms. Under this release, an
SMP NLM replaces the NetWare OS kernel that comes with 4.x. SMP's multiprocessor
performance is comparable to that of NT, and scales well with additional CPUs. NetWare
4.1 SMP is currently available only from server hardware vendors, but Novell is also
planning to introduce a shrink-wrapped version.
Basic Architecture
The server aspect of NetWare was designed to operate in a dedicated, Intel-based
system. Although NetWare has been ported to non-Intel systems where it can run alongside
other applications, the majority of NetWare installations are, in fact, dedicated,
Intel-based servers. In this environment, the core NetWare system is launched from
DOS--you boot up the server under DOS and then run NetWare. At that point, NetWare
takes over the system and DOS is no longer the dominate operating system.
The configuration and management of a NetWare system can be performed at the system
console, which is the keyboard and the monitor attached to the system. The system
console provides a simple, character-mode interface for configuration and administration
tasks. Alternatively, NetWare contains a remote console utility that enables you
to perform most console functions from a client workstation. In contrast, the configuration
and management of the NetWare user environment is typically performed from a client
workstation using an administration tool.
Originally, NetWare used server-based security that required each user to log
on to every server on which he or she needed resources. With the advent of NDS, however,
user permissions can be set up on a network-wide basis, and each user simply has
to log on to the network once. After a user logs on, NetWare can activate a user-specific
batch program (a log on script) that allocates the resources the user accesses on
a regular basis. For example, the log on script can mount NetWare directories as
network disk drives so the user can access specific applications or business data.
The configuration of the client-side software that handles the communication between
the client system and the NetWare server(s) has changed dramatically as NetWare has
evolved. For NetWare releases prior to 3.12, the client-side software that handles
traffic to/from the network adapter has to be "generated" using the NetWare
utility WSGEN.
WSGEN is an interactive program that combines software that handles the physical
network adapter in a client PC with software that implements the NetWare IPX protocol.
WSGEN outputs a program file called IPX.COM that must be loaded in each PC prior
to accessing the NetWare network. You need a version of IPX.COM for every unique
type of network adapter in your PC network, and you must make sure each version of
IPX.COM pairs with the network adapter it was generated to use.
In a pure NetWare environment, you load IPX.COM in the AUTOEXEC.BAT file. Because
IPX.COM handles all the network adapter functions, NetWare requires no CONFIG.SYS
device drivers. After IPX.COM loads, a second NetWare program, NETX.COM, is launched
to integrate the NetWare functions into the DOS environment. After NETX.COM loads,
you can log on to a NetWare server and start accessing NetWare services (for example,
drivers, printers, NetWare Loadable Modules).
By most standards, interactively generating an executable file (in other words,
IPX.COM) to handle each type of LAN adapter is less than ideal, especially if you
have more than one type of adapter in your network. For example, if you're installing
a workstation in a remote department and you bring the wrong IPX.COM file, you're
basically out of luck. You also have an issue of version control--if you generate
multiple IPX.COM files, you have to figure out how to identify which file applies
to which adapter.
Given the awkward nature of WSGEN, network vendors looked at the problem of marrying
proprietary protocols to a wide range of network adapters and tried to find a better
approach. One of the key outcomes of this investigation came in 1988 when IBM, Microsoft,
and 3Com introduced the Network Driver Interface Specification (NDIS) as part
of the OS/2 LAN Server. NDIS addresses the problem of marrying adapter boards to
protocols by dividing the functions into two logical layers:
- Adapter interface layer. Manages and communicates with the physical adapter.
The adapter interface presents a "generic" interface to the network interface
layer (described below), so every adapter essentially looks the same.
- Network interface layer. Implements the desired network protocols (for
example, NetBIOS/NetBEUI or TCP/IP) and communicates with the physical adapter via
the "generic" interface the adapter interface layer provides.
Novell was not blind to NDIS's development. But instead of embracing NDIS, Novell
created its own solution--the Open Data-link Interface (ODI). Like NDIS, ODI
separates the physical network adapter's functions from those of the network protocol.
Despite the apparent similarities, however, ODI is not compatible with NDIS (although
NetWare does include an ODI "shim" module--ODINSUP--that enables
NDIS and ODI traffic to coexist on the same physical adapter).
Novell's ODI standard requires certain files and programs to integrate network
protocols with a wide variety of network adapters. Unlike Microsoft's Network Driver
Interface Specification (NDIS), ODI does not require any device drivers in the CONFIG.SYS
file. Instead, ODI operates from a batch file (normally the AUTOEXEC.BAT startup
file) or directly from a command prompt. The ODI programs include:
- LSL.COM. The Link Support Layer (LSL) program is NetWare's ODI
baseline program. It interfaces with vendor-supplied adapter programs and provides
a consistent interface to the higher-level ODI modules.
- XXXXXXXX.COM. Each network adapter manufacturer provides a software driver
that operates with the LSL program. For example, the SMC8000.COM program provides
an interface to the Western Digital and SMC line of Ethernet Plus adapters.
Specific programs are then layered on top of the previous two files to implement
network-specific features and functions. These files are:
- IPXODI.COM. This program implements NetWare's core IPX protocol suite
over the underlying ODI drivers. It is analogous to the IPX.COM program used in pre-ODI
environments.
- VLM.EXE. The Virtual Load Module (VLM) program starts specific
NetWare work- station services based on the configuration file (described in the
following paragraph). This program is the analogous to the NETX.COM program used
in pre-ODI environments.
All the programs obtain configuration information from the NET.CFG file, a text
file that defines the hardware's operational characteristics (for example, IRQ setting,
port value, and DMA address), the operating parameters for the various ODI programs,
and the interrelationships between the programs.
NetWare also includes client software for other, non-PC clients. Although the
implementation details for these other environments are obviously different then
for a PC environment, they all accomplish the same net result--a connection to a
NetWare server.
Network Support
As previously noted, NetWare typically relies on the Internet Packet Exchange
(IPX) protocol as the network transport between the client and server systems. Although
Novell is aggressively moving toward supporting TCP/IP instead of IPX, the majority
of NetWare installations still use IPX as the primary transport.
In reality, IPX is not really a single protocol, but actually a suite of protocols
(much like TCP/IP). IPX can carry a number of service protocols, including the Sequenced
Packet eXchange (SPX) protocol. By itself, IPX is a connectionless protocol that
does not guarantee delivery of messages. SPX, on the other hand, is a connection-oriented
protocol that runs as an extension to IPX and provides confirmation (or denial) of
the end-to-end delivery of messages.
NetWare service protocols can run under just IPX, or the IPX/SPX combination.
These services include:
- NetWare Core Protocol (NCP). This protocol handles the mainstream NetWare
services, including accessing files and printers on NetWare servers.
- Burst Mode Protocol. This is a variation of the NetWare Core Protocol.
Designed for high-volume applications, Burst Mode enables a client to request and
receive more data in a single message than under NCP.
- Service Advertising Protocol (SAP). File, print, communication, and other
types of servers announce themselves at regular intervals using this protocol. Client
PC's "listen" for this protocol to determine what resources are available
within the network. Clients can also use this protocol to inquire about the capabilities
of specific servers.
- Routing Information Protocol (RIP). This protocol is used to help a message
move from one NetWare network to a second NetWare network. Routing protocols like
RIP is an important factor in how wide-area networks are constructed.
The IPX protocol suite is clearly one of the factors contributing to NetWare's
success because IPX has a number of advantages over the two other protocol suites
commonly used in PC LANs (in other words, NetBIOS/NetBEUI and TCP/IP). These advantages
include:
- Unlike TCP/IP, IPX does not require an extensive addressing scheme for clients
and servers. IPX, like NetBIOS/NetBEUI, relies on the hardware addresses burned into
network adapters.
- Although IPX does not implement its own system-level addressing scheme, it is
a fully routable protocol (that is, it supports network address assignments). Because
IPX is fully routable, you can interconnect multiple NetWare LANs in a relatively
simple fashion. In contrast, TCP/IP is also fully routable but NetBIOS/NetBEUI is
not.
- IPX is a relatively efficient protocol because it does not rely on client-initiated
broadcast messages to establish client/server connections (as is the case in NetBIOS/NetBEUI)
and it uses bit-based flags in its headers (unlike TCP/IP, which uses byte-based
flags).
Microsoft Windows NT Server
Windows NT Server is the result of the successes and failures Microsoft has experienced
with its earlier products and projects. Windows NT Server was clearly affected by
the success of LAN Manager and Windows for Workgroups, as well as the failure of
Microsoft's involvement with OS/2. If nothing else, Windows NT Server (and Windows
NT Workstation) is a genuine commercial-class operating system--Microsoft's first
entry into the marketplace of enterprise-oriented data processing.
Windows NT Server has not always been the darling of the industry. In fact, the
early releases of the product weren't exactly welcomed with enthusiasm. The first
change that steered Windows NT towards its current success came with the 3.51 release
of Windows NT--a release that introduced support for native Microsoft file and print
services over TCP/IP, IPX, and NetBEUI. This seemingly subtle change in networking
support enabled Windows NT to be easily deployed in existing networks.
Although version 3.51 enabled Windows NT to enter into new corporations and gain
new respect and appreciation in the industry, that change was nothing in comparison
to the changes that occurred in version 4.0 of Windows NT. Version 4.0 featured the
same user interface as Windows 95, which positioned Microsoft as a provider of a
complete client/server solution with a consistent, easy-to-use and easy-to-manage
user interface and user environment.
Of course, version 4.0 also contained significant improvements over 3.51. For
example, all of the NetWare coexistence/migration tools (further discussed in the
"NetWare/Windows NT Server Integration" section at the end of this chapter)
were included on the distribution CD (they had previously been sold separately).
Windows NT Server 4.0 also featured better TCP/IP integration, including the capability
to operate as a DNS server and as a Web server (via the Internet Information Server
included on the distribution CD). Support for TCP/IP integration is proving to be
a critical component for Windows NT.
Window NT 5.0 and the Internet
In the future (5.0) release of Windows NT, the desktop environment will be Internet
aware--enabling you to open up a Web page just as easily as you can open a document
on your hard disk. Furthermore, many of the enhancements to 5.0, including Microsoft's
new directory services, are only targeted to run under TCP/IP. Microsoft is clearly
betting that TCP/IP will be the protocol suite of choice in most public and private
networks.
Another subtle change that occurred after the 4.0 release of Windows NT was Microsoft's
approach to new products. Prior to 4.0, the details of new products and features
were kept under wraps. After 4.0, however, Microsoft began a massive program of announcing
and releasing beta versions of most of its new products via the Internet. Although
Microsoft originally began this effort to better position its free Internet Explorer
Web browser against Netscape's Navigator web browser, the program has since grown
to epic proportions.
One final key point that separates Windows NT Server from NetWare is that Windows
NT Server is clearly more than just a file and print server--Windows NT Server is
an application server. Unlike NetWare, which requires vendors to write NLMs, Windows
NT Server can host conventional, Windows-based applications. Client/server connections
can be accommodated to these applications using direct program-to-program communication,
ODBC (a distributed data base connection), and more recently ActiveX (a network-based
Object Linking and Embedding solution).
Microsoft's commitment to delivering an application server can be seen in its
investment in the BackOffice suite of programs. BackOffice contains a powerful
database component (SQL Server), a mail/messaging component (Exchange), a legacy
connectivity component (SNA Server), a system management component (SMS), and a fast-growing
variety of Web-based applications built around Microsoft's Internet Information Server.
In fact, for several years Microsoft was willing not to challenge NetWare for
traditional file and print business, concentrating instead on the application server
focus. Microsoft's reasoning was that if it could get a Windows NT Server into a
corporation as a mission-critical application server, the file and print business
would eventually migrate to them anyway. This has proven to be a successful strategy,
although recently Microsoft has become more willing to compete head-to-head with
NetWare for conventional file and print server business.
Basic Architecture
Windows NT Server can be hosted by systems using Intel or DEC Alpha processors.
Earlier in its history, Windows NT Server also supported MIPS processor systems;
however, MIPS will no longer be supported as of the 5.0 release of Windows NT. Support
for NT on the PowerPC has also been phased out by both Motorola and IBM, and it is
unlikely that Microsoft will continue to support the PowerPC architecture in subsequent
releases.
The basic functions of Windows NT Server are consistent across all these types
of systems, but additional application programs might not be available for all processor
types. For this reason, Intel-based machines are deployed in the majority of Windows
NT Server installations.
In addition to supporting different types of systems, Windows NT supports Symmetrical
Multi-Processing (SMP); therefore, Windows NT can immediately take advantage of systems
with multiple CPUs. You can deploy a Windows NT Server in a one- or two-processor
configuration and then upgrade it to a three- or four-processor configuration when
you need additional performance improvements. Obviously, the base hardware system
you're using to host Windows NT Server must support multiple processor configurations
for you to perform this kind of upgrade.
Processor configuration aside, Windows NT Server runs as a non-dedicated operating
system--you can use the same system for desktop applications if you so desire (however,
most corporations prefer to run Windows NT Server as a dedicated system). In fact,
Windows NT Server is very similar to its desktop counterpart, Windows NT Workstation.
Detailed analysis has shown that the operating system kernel is the same for both
products. Windows NT Server has, however, been fine tuned for server performance
and includes additional software not available for Windows NT Workstation.
The fact that Windows NT Server has a full GUI appearance makes it relatively
simple to configure and administer all aspects of the server environment. You can
manage a Windows NT Server from the local keyboard and monitor and, as in the case
of NetWare, you can manage it from other workstations in the network. However, many
of the configuration and testing utilities are still command-line based.
In terms of security, Windows NT offers two types of security models: workgroups
and domains. In a workgroup model, the user authentication process occurs
on each system in the work-group. Other workgroup systems "trust" that
each system has performed the authentication. In a domain model, however, all users
are authenticated by a central server (termed the domain controller). Using a centralized
server provides greater control and security.
From a broader perspective, workgroups are informal groupings of systems that
elect to share resources with one another. Domains, on the other hand, are formal
collections of systems that can be centrally controlled and administered. The informal
nature of workgroups makes it difficult to implement them as large, enterprise-wide
solutions.
Unlike workgroups, domains can be interconnected. When you interconnect domains,
you can establish trust relationships between them so a user logged on to one domain
can access resources in another domain without being forced to log on to the second
domain. Although this approach works well in simple organizations, trust relationships
can grow very complex in large organizations. (For that reason, Microsoft is moving
toward global, NDS-like directory services. These new directory services are planned
for availability in the 5.0 release of Windows NT.)
One of the most unique aspects of Windows NT networking is how Windows NT sepa-
rates client/server and peer-to-peer services from the underlying network protocol.
Under Windows NT, you can choose the protocol you want to use in your network--NetBEUI,
IPX, or TCP/IP--without worrying how it will affect Windows NT services for file
sharing, printer sharing, and program-to-program communications. This flexibility
enables you to construct and administer powerful networks that can address the needs
of your company without being compromised by the demands of your existing client
or server computers.
Microsoft's model for integrating network protocols with network adapters is,
of course, the NDIS model previously discussed in this chapter. Microsoft's implementation
of NDIS has, however, gone through dramatic changes to keep pace with Microsoft's
relentless march of new operating systems.
For example, when NDIS originally started out in the DOS environment, it was a
completely static model where all protocols had to be bound to the network adapters
at boot time via the CONFIG.SYS file and then activated via a "NETBIND"
command in the AUTOEXEC.BAT file. The detailed information about adapter settings
(IRQ, DMA, port address, and so on) and about the protocols was placed in a separate
PROTOCOL.INI file.
After all of the protocols were locked and loaded, you could not add new protocols
nor could you unload any running protocols without reconfiguring your system and
rebooting it. This structure worked fairly well for DOS but it proved to be difficult
to operate under Windows. Therefore, Microsoft made some subtle changes to its NDIS
support when it introduced Windows for Workgroups.
Under Windows for Workgroups, Microsoft moved the PROTOCOL.INI file into the Windows
directory and moved some of the information that had been contained in the file into
some of the standard Windows configurations files (for example, SYSTEM.INI and WIN.INI).
Microsoft also introduced the NDIS Demand Protocol Architecture (DPA). Under
DPA, network interface drivers can be loaded as terminate-and-stay-resident (TSR)
routines from the DOS command line (or AUTOEXEC.BAT file) instead of as device drivers
from the CONFIG.SYS file.
Despite the integration into Windows for Workgroups, NDIS support remained mainly
under the control of DOS. The network protocols were set up and activated before
Windows was even launched. This same strategy could not work under Windows 95 and
Windows NT because neither of those operating systems feature an underlying DOS layer
to handle NDIS functions. As a result, NDIS had to be completely integrated into
Windows 95 and Windows NT. Of course, you still need to reboot your system to activate
any changes you make to your protocol environment.
Windows NT Server contains client software for all PC environments (DOS, Windows,
Windows for Workgroups, and Windows 95). Windows NT Server has the capacity to emulate
a Macintosh file and print server; therefore, some level of integration is available
with Macs without requiring any changes or new software in Mac clients. Support for
UNIX clients and other clients must be obtained from third-party companies.
Network Support
In order to appreciate the advantages of the Windows NT multi-protocol network
support, you need to look back at the original networking model used by IBM, Microsoft,
and others. This model was created in 1984 when IBM and Sytek released a LAN-based
message interface system named the Network Basic Input/Output System, better
known today as NetBIOS. NetBIOS is a generalized program-to-program communication
facility that enables peer-to-peer and client/server communications between PCs operating
in a LAN environment.
NetBIOS facilitates communication through three key services:
- Name service. Each PC using NetBIOS is assigned a logical name (for example,
MKT1, SALES, KELLY, and so on), and other PCs use that name to communicate with that
PC. PCs learn about one each others names by listening to announcements PCs make
when they join the LAN (for example, "MKT1 now available for service")
or by broadcasting a discovery request for a name (for example, "KELLY, are
you there?"). Each PC keeps track of the names of other PCs in a local, dynamic
table. No centralized name servers are required (or supported).
- Session service. A PC can establish a session with another PC by "calling"
it by name. After the target PC agrees to communicate with the requesting PC, the
two PCs can exchange messages with one another until one of them "hangs up."
Session service is a connection-oriented service, so while the two PCs are communicating
with one another, NetBIOS provides message sequencing and message acknowledgments
to insure that all messages sent are properly received.
- Datagram service. Datagram service is a connectionless service that does
not require a PC to establish a session with another PC in order to send messages
and does not guarantee the receipt of any messages sent. Datagram services can be
used to deliver broadcast or informational messages. Application-level session controls
and acknowledgments can also be placed on top of datagram services to make them more
reliable.
In addition to these three core services, NetBIOS provides a limited number of
status and control functions. For example, these functions can be used to cancel
a NetBIOS request, discover the current status of the NetBIOS interface, or start
a NetBIOS-level trace.
When NetBIOS was first released, the term NetBIOS encompassed both protocol-level
and service-level functions. As the industry moved toward using well-defined computing
models that separate protocols from services (among other things), the NetBIOS protocol
and service aspects were formally separated and the term NetBIOS Extended User
Interface (NetBEUI) was adopted to define the protocol-level functions.
Microsoft pioneered the usage of the term NetBEUI and included support for the
NetBIOS/NetBEUI combination in its DOS-based LAN Manager product, in its Windows
for Workgroups (WFW) offering, and, of course, in its Windows NT Workstation and
Server products. Unfortunately, while Microsoft clearly distinguishes between the
NetBIOS and NetBEUI functions, many other vendors continue to use the term NetBIOS
to refer to both protocol and service functions.
As noted, NetBIOS provides a generalized interface for program-to-program communications.
NetBIOS does not, however, provide specific services to facilitate file, print, and
other user-related services in a peer-to-peer or client/server LAN. That task falls
on the shoulders of Server Message Blocks (SMB).
Like NetBIOS, SMB is an interface system. But where NetBIOS is a generalized interface
system, SMB is a specific interface system that enables file sharing, print sharing,
and user-based messaging. Some of the specific services supported by SMB include:
- Connection Related Services
Start/end connection
Get disk attributes
Create/delete directory
Search for file name(s)
Create/delete/rename file
Read/write file
Lock/unlock file area
Open/commit/close file Get/set file attributes
Open/close spool file
Write to spool file Query print queue
Discover home system for user name
Send message to user
Broadcast message to all users
Receive user message(s)
In the Windows NT environment, SMB functions are integrated into the operating
system. For example, when you use File Manager to connect to a network drive (or
you issue a "NET USE" command), you are invoking SMB functions. Also note
that NetBIOS and SMB often work together. For example, when you go to connect to
a network drive, you rely on NetBIOS services to find the name of the system sponsoring
the directory you need, but you actually connect to and access that network drive
using SMB services.
As successful as the SMB/NetBIOS/NetBEUI architecture has been, it is not without
its limitations:
- As discussed earlier, NetBIOS uses system names to enable and manage end-to-end
connections. Under NetBIOS, names are resolved using broadcast-oriented techniques.
For example, when a system joins the LAN it broadcasts its name and when a system
wants to establish a connection to a system it has not previously heard from, it
broadcasts a name discovery message. Unfortunately, broadcasts create overhead in
a LAN and can negatively affect overall performance.
- NetBEUI does not use any addresses other than the physical LAN adapter address
(also known as the Medium Access Control, or MAC, address). In contrast,
protocols like IPX and TCP/IP add a second level of addressing that defines a network
address. This second level address enables IPX and TCP/IP to quickly determine if
a transmitted message needs to be routed to another physical network (because it
has a different network address) or if it can be serviced on the local network. Because
NetBEUI does not use a second level address, NetBEUI cannot distinguish between local
and non-local messages, and is therefore considered a non-routable protocol.
When you combine the NetBIOS limitation with the NetBEUI limitation, you end up
with network traffic that is difficult to manage over multiple, interconnected LANs
or in a complex LAN/WAN environment. Specifically, you have NetBIOS generating lots
of broadcast messages to resolve names, and because NetBEUI does not support network
addressing, these broadcasts must be sent to all of the attached LANs. In effect,
NetBIOS and NetBEUI aggravate each other's limitations.
Fortunately, Microsoft recognized the limitations of NetBIOS and NetBEUI and included
alternate approaches in the network architecture for Windows NT. Under Windows NT,
you are not forced to run NetBIOS and SMB over NetBEUI--you can, in fact, choose
the network protocol that makes the most sense for your organization's overall network
composition. Because you are no longer forced to use NetBEUI for native Microsoft
networking traffic, you are no longer constrained by the NetBEUI limitation.
What LAN-level protocols can you choose from? Microsoft provides three protocols
that can be used to carry NetBIOS and SMB traffic:
- NetBEUI Frames (NBF). This is an enhanced version of NetBEUI that supports
a larger number of systems than the original NetBEUI protocol. Unfortunately, the
enhanced version does not include any network addresses and therefore still suffers
from the same internetworking limitation as the original protocol.
- Internetwork Packet eXchange/Sequenced Packet eXchange (IPX/SPX). As noted,
IPX and SPX are the main protocols used in Novell NetWare networks. IPX is a connectionless
protocol with no guaranteed delivery and SPX is a connection-oriented protocol with
guaranteed delivery.
- Transmission Control Protocol/Internet Protocol (TCP/IP). TCP/IP is actually
a suite of protocols that include TCP, IP, the User Datagram Protocol (UDP), and
several other service protocols. TCP is a connection-oriented protocol with guaranteed
delivery and UDP is a connectionless protocol with no guarantees. Both TCP and UDP
rely on IP to resolve network addresses and facilitate the end-to-end delivery of
messages.
As previously noted, TCP/IP and IPX implement network addresses; therefore, they
are both considered routable protocols that can easily be integrated into multi-LAN
environments and large wide area networks. This makes either protocol a superior
choice to NetBEUI for most applications.
Unfortunately, the standard implementations of TCP/IP and IPX do not address the
broadcast-intensive nature of NetBIOS. Because NetBIOS operates above the LAN-layer
protocol, it is isolated from the technical details of the underlying protocol, and
by the some token, the underlying protocol is isolated from the technical details
of NetBIOS. That means that NetBIOS name resolution will, by default, be handled
using broadcast techniques, regardless of which LAN-layer protocol is in use.
Microsoft did, however, address this problem by creating optional enhancements
for the TCP/IP implementation in Windows NT--and only for the TCP/IP implementation.
Specifically, Microsoft borrowed an idea (or two) from the way TCP/IP is implemented
in a UNIX environment and implemented three ways of resolving NetBIOS name requests
without generating broadcasts:
- LMHOSTS. You can configure a LMHOSTS file in each Windows NT system. LMHOSTS
is a simple text file that contains a list of NetBIOS names and the corresponding
TCP/IP address for each name. This is similar to the way that UNIX hosts use a HOSTS
file to resolve native TCP/IP name-to-address translations. (You should note that
Windows NT also supports a HOSTS file for TCP/IP traffic that does not involve NetBIOS.)
- WINS. You can implement a Windows Internet Name Service server.
A WINS server provides a centralized database that maps NetBIOS names to TCP/IP addresses.
When a WINS client wants to know the address for a NetBIOS name, it simply asks a
WINS server. This is similar to the way that UNIX hosts use Domain Name System (DNS)
or Network Information Service (NIS) name servers.
- DNS. You can also use a DNS server (UNIX or Windows NT Server) to resolve
NetBIOS names into TCP/IP addresses. Microsoft is currently moving away from WINS
and toward DNS as its preferred method of NetBIOS name resolution.
A given Windows NT system can use any one or a combination of any of these approaches.
In the event none of the above approaches are used, the NT system will resort to
using broadcasts for name resolution. Assuming, however, that one of these approaches
is in place, the TCP/IP software in a Windows NT system will look for NetBIOS name
discovery requests. When it sees such a request, it will send an inquiry request
to a WINS server or look for the name in its local LMHOSTS file.
Finally, please note that the Windows NT implementation of TCP/IP also supports
a dynamic IP address assignment protocol--the Dynamic Host Configuration Protocol
(DHCP). DHCP greatly simplifies the configuration of client systems in a TCP/IP
network. Instead of assigning and configuring unique IP addresses in each client
PC, you simply configure them to use DHCP and they will automatically receive an
IP address assignment from a DHCP server system (typically a Windows NT Server system).
The real beauty (from a networking perspective) of the Windows NT environment
is that it enables you to deploy multiple protocols on a concurrent basis. With Windows
NT you can run native Windows NT networking services over IPX and run native TCP/IP
services (in other words, Telnet, and ftp) over TCP/IP. Alternatively, you can run
native NetWare services over IPX and run native Windows NT networking services over
TCP/IP. You can even deploy all three protocol suites--NetBEUI, IPX, and TCP/IP--and
enable native and non-native services over all of them.
Microsoft and TCP/IP
As Microsoft continues to enhance Windows NT, the multi-protocol scenario will begin
to change because Microsoft is making a greater investment in TCP/IP-based services.
For example, in the 5.0 release of Windows NT, all of the new directory services
will only be available if you are using TCP/IP as your primary transport. Microsoft
clearly believes that TCP/IP will be the de facto network protocol for the majority
of the industry. You will, of course, still be able to run the other protocols, but
if you do not run TCP/IP as well, you will find yourself feature-limited.
NetWare/Windows NT Server Integration
The reality is that many organizations choose to deploy both NetWare and Windows
NT Server. For example, a company might use NetWare for file and print serving, but
use Windows NT Server as a data base server for client applications. This kind of
coexistence results in a requirement for a client systems to be able to access both
types of servers.
Because Microsoft operating systems control the majority of desktop environments,
it should be no big surprise to discover that Microsoft is the primary provider of
NetWare/Windows NT Server coexistence solutions. NetWare/Windows NT Server coexistence
solutions take on three forms:
- Concurrent access. Running two sets of client software in each desktop
system so each client system can access both servers concurrently.
- Emulation. Using a Windows NT Server to emulate a Novell server so clients
can use existing NetWare client software to access NT resources.
- Gateway. Using a Windows NT Server as a gateway so that clients see the
NetWare server as part of the Windows NT Server system.
The first solution--running two sets of client software in each desktop system--is
really only practical if the desktops are running Windows for Workgroups, Windows
95, or Windows NT Workstation. These three operating systems can easily support concurrent
access to two different types of servers. You can use Novell-provided client software
in all of these three cases, or you can use the Microsoft-provided NetWare client
software in the Windows 95 and Windows NT Workstation environment.
Although concurrent access to both types of servers is technically possible in
DOS and Windows environments, it is very difficult to implement and manage. If you
are operating in either of these environments, you are better off looking at the
other two approaches.
The second solution--having a Windows NT Server emulate a NetWare server--is accomplished
via the NetWare file and print services included in the 4.0 release of Windows NT
Server. After this software is installed, the Windows NT Server emulates a NetWare
server and clients can connect to it to access file and print resources using standard,
client-side NetWare software. In most cases, this solution is implemented as a migration
strategy--clients are given access to both servers as information is moved from the
NetWare server to the Windows NT Server systems. After everything is moved, the clients
are then switched to native Microsoft client software.
The final solution--using Windows NT Server as a gateway to a NetWare server--is
implemented by using the NetWare gateway software included in the 4.0 release of
Windows NT Server. This software establishes a connection to a NetWare server and
remaps all of the files and printers into native Windows NT Server format--client
systems see the NetWare resources through standard Microsoft client software. This
approach is somewhat limited in that access to the NetWare server is performed via
a single-user id--all of the client systems share the access rights of the gateway
user-id.
Finally, you should note that a wide variety of third-party software is available
to integrate both NetWare and Windows NT Server into UNIX and other operating system
environments. The bottom line is that neither of these products suffer from a lack
of connectivity options--either to one another or to the rest of the world.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
