Internet Core Protocols: the Definitive Guide

January 1, 1996

An Overview of Windows 3.x' NBT Services

Windows for Workgroups' native networking architecture provides users in a small local area network with limited file- and printer-sharing capabilities. Users can connect to other Windows for Workgroups PCs, and use other systems' shared resources.

This functionality is a result of the combined functionality offered by a collection of various networking components.

Network Driver

At the top of the heap rests the network driver. Just as Windows has video "drivers" that tell the operating environment about specific features that your video adapter offers, it also has drivers that inform it about the network operating systems in use on the PC. These drivers provide a browsable interface to the network, generally through File Manager and Print Manager.

Some TCP/IP suites provide an NFS driver for example, allowing users to browse and connect to remote NFS servers through File Manager, or allowing users to browse and connect to remote LPD printers through Print Manager.

Windows for Workgroups' native network driver is an adaptation of the LAN Manager Windows client driver from Windows 3.1. It provides a browsable interface to servers based on Microsoft's LAN Manager. This includes Windows for Workgrous, Windows NT, Windows 95, Digital PathWorks, SAMBA, and several other products.

The network driver itself only provides an interface to the network resources. It does NOT provide any protocol or service functions.

NOTE: The network driver is not to be confused with the network ADAPTER driver. The network adapter driver is generally DOS-based, and is part of the user's ODI or NDIS installation, providing an interface between the low-level protocols and the network adapter itself. The network driver on the other hand provides an interface between Windows and the network operating system.

Redirector and Server

The client redirector is what handles the presentation of resources on the network. This module handles user account security, resource availability, the actual "connection" to a remote server's resource, and other network operating system-specific functions. Essentially, once two computers are able to communicate with each other, the redirector provides the local operating system with the ability to access the remote system.

For example, File Manager doesn't understand network concepts explicitly, but instead relies on the redirector to handle requests for it. If you connect to a remote server and list the files in one of its directories, these requests are passed to the Windows kernel which checks to see if the resource is local or remote. If it is remote, it passes the request to the redirector, which passes it to the remote system. That system processes the request, and returns some sort of answer. The redirector then passes the data back to the kernel for presentation to the application that requested it.

Windows for Workgroups also provides a server component that listens for requests from remote systems. If you have enabled file sharing on your PC and another user connects to your system, then his redirector is talking to your server. The server is, in essence, the opposite of the redirector. However, the server also relies on the redirector to provide the interface to the network for it. When the server wishes to advertise a resource, it publishes the information with the redirector, which then sends the information out onto the wire.

Server Message Blocks (SMBs)

When two Windows for Workgroups nodes communicate, they must use a common set of commands. They can't just pass arbitrary strings of data around the network. With Windows for Workgroups and other derivatives of LAN Managers, a "dictionary" of network-I/O commands is provided by the X/Open-standard Server Message Blocks (SMBs). SMBs provide a well-defined method for servers and nodes (called "consumers" in the SMB definition) to communicate with each other.

The SMB specification is comprised of a list of network commands. For example, if a user wants to open a file that resides on a server, then the SMB command "SMBopen" is passed between the two systems. This occurs at the redirector level. The client PC's redirector sends the SMBopen command to the server PC's redirector module, which passes the request up to the server, which then interprets the request, and hopefully sends the file back to the client PC.

SMB commands exist for a wide range of functions, and provide a quick and cost-effective way to do the most common network functions. Commands exist for things like login security, printing, and working directly with files and directories. In other words, the SMB protocol is the heart of the network, providing a common language for all the clients and servers to use.

Note that by implementing SMBs on different systems, the client is able to communicate with them. If those systems were not running SMB-based servers, then the redirector would not be able to communicate with them. This is also very similar to the NFS model. As long as you've got an NFS server component on a system, then NFS clients can connect to it and exchange data.

NetBIOS Applications

Just as there are file- and print-sharing mechanisms, there are also generic network applications that communcicate between multiple systems. In the TCP/IP world, these applications are FTP, the World Wide Web, Internet Relay Chat (IRC) and many others. In the Windows for Workgroups world, these applications are generally NetBIOS-based, and not TCP/IP-based.

Two of the NetBIOS applications that come with Windows for Workgroups include the Chat and ClipBook applets. They allow users to connect with other NetBIOS systems and exchange data. These programs do NOT use SMBs since they are not tied in to the redirector. However, they are similar to the redirector/server model since they are node-to-node communcations. They can use a common set of commands similar to SMBs, but these commands are determined by the applications themselves.

NetBIOS applications range from the simple Chat-like applets to mainframe gateways and multi-user databases. Any application that needs to communicate with another can use the NetBIOS APIs to do so. Lotus' Notes server for Windows is a NetBIOS application, for example. Also, Microsoft Mail for Windows NT can support NetBIOS. This allows one NT mail client to notify another client that new mail has been sent, using a NetBIOS message. The normal method requires that the recipient workstation check the inbox on a fileserver's shared drive for any unread messages.

NetBIOS the API

NetBIOS applications and the redirector component of Windows for Workgroups all communicate with other machines through the use of the NetBIOS API.

A little history of NetBIOS is perhaps in order here. Several years ago, IBM developed NetBIOS with the goal of developing a network protocol that would work on small networks of PCs. The keyword in that sentence is "small". At the time, the practical limit for an ethernet segment was 30 nodes, while IBM's own vaunted and un-delivered Token Ring was limited to 255 nodes. There was no need to build in capabilities for moving data between multiple network segments, since nobody was doing it, and the use of gateways to link networks was assumed.

Thus, the design goal was to build a very small and fast protocol. The protocol would provide APIs for the development of network-specific applications that could communicate on a machine-to-machine, or application-to-application basis. Also, the network naming system would allow for human-assigned names of devices, like "MyServer," which is easier to remember and work with than a complex numbering scheme such as TCP/IP. Unfortunately, this design breaks down very quickly in minorly-complex networks, and is completely non-scalable.

NetBIOS was (and continues to be) a broadcast-intensive protocol. Since the assumption was that there were only a few nodes on the network, and that devices would be appearing and disappearing at random (as PCs are apt to do), then it was best to be able to locate a device with a broadcast rather than with any sort of centralized registry. Unfortunately, broadcast packets don't work in today's router-based networks, since the routers don't pass packets that aren't specifically destined for another network node. And since the NetBIOS naming structure is non-hierarchial, devices can't specify remote network segments. Thus, the only way to make NetBIOS work in large networks is to bridge the various segments into a large virtual network. Unfortunately, NetBIOS' reliance on broadcasting limits its use to relatively small networks, so large bridged networks don't work very well either.

NetBIOS uses machine and application names to identify nodes and services available on the network, and for all exchanges of information between them. When Windows for Workgroups starts up, it broadcasts its assigned workstation name, and if no other node challenges the name (or claims to be using it already), it keeps the name for itself. It does not necessarily register the name anywhere, but instead each node is responsible for maintaining its own name tables. If a subsequent node comes on the net and claims the same name, it is the responsibility of the first node to challenge the new one.

Likewise, when a node needs to communicate with another node, it uses broadcasting to find the remote system. The remote system is responsible for responding to the broadcast with a directed reply. Once nodes have identified each other, they can communicate with directed messages.

If you have a NetBIOS application and you wish to communicate with another system or user who is also running that application, then your client will issue a broadcast for the application's NetBIOS name. If the node you are trying to communicate with does not receive the broadcast, then he will not respond, and your client should timeout gracefully. Once your application has located its partner, they will communicate directly.

NetBIOS-over-TCP/IP (NBT)

Fortunately, the NetBIOS APIs can be used with any low-level transport protocol -- such as TCP/IP. Unlike NetBIOS, TCP/IP is completely routable. Indeed, it is predominantly a point-to-point protocol that avoids broadcasting whenever possible. Thus, using TCP/IP as a way to move NetBIOS-based data is an attractive alternative to the flat and non-routable NetBEUI protocol that is the default in Windows for Workgroups.

Since NetBIOS uses names for addressing purposes while TCP/IP uses numbers, there must be some way to map the two so that both of them see what they expect. In order for NetBIOS-based applications to run over TCP/IP networks, the NetBIOS application must see names, and the IP protocol must see numbers, yet neither can see the other. A layer between the two must map NetBIOS names to IP addresses, and convert IP addresses back to NetBIOS names. This layer is known as NetBIOS-over-TCP/IP.

TCP/IP standards are defined by Requests for Comment, or RFCs. Anyone may submit an RFC for consideration as a standard (even you). Two such RFCs are 1001 and 1002, which define a standard method for running NetBIOS over TCP/IP. RFC 1001 defines a general overview, while RFC 1002 defines the details.

There are three types of NetBIOS nodes defined in these two RFCs. A b-node (broadcast node) is one that uses broadcasting to query nodes on the network for the owner of a NetBIOS name. A p-node (point-to-point node) uses directed calls to communicate with a known nameserver (not to be confused with DNS) for the IP address of a NetBIOS machine name. An m-node is a mixed node, one that uses broadcasted queries to find nodes, and failing that, queries a p-node nameserver for the address. Another type currently under review is an h-node, which reverses the m-node standard so that a directed query is executed first, and failing that, a broadcast is attempted. Remember that the node types apply only when a node is attempting to match an IP address to a NetBIOS node name. Once the device has discovered the IP address of the machine it's trying to communicate with, it no longer broadcasts information, but sends the IP traffic directly to the node associated with the NetBIOS name.

NetBIOS Name-to-IP Address Resolution Schemes

NBT can use a variety of mechanisms for name resolution. The simplest conceptual and practical method is to simply rely on the default of using broadcasts to locate network resources. This calls for the node to issue TCP/IP broadcasts for every NetBIOS query. Hopefully, the partner system is on your local network, and will see and respond to the broadcast. If you need to be able to configure more exacting name resolution patterns for more complex environments, then you will want to use on of the more powerful options available.

NBT can convert NetBIOS names to IP addresses in several ways. The one described above -- broadcasting -- hardly seems suitable in anything except the most simple networks. Another potential way to resolve the name is to pre-load the NBT name cache with an IP address. This is accomplished using a text file called LMHOSTS. Another option is to use Windows Internet Name Service (WINS) servers. A WINS server is essentially a p-node as described in RFCs 1001 and 1002, although as an implementation it is proprietary to Microsoft. You can also use your DNS servers as name servers, although this is very limited in functionality.

Assuming you have any of these name resolution options enabled on your Windows for Workgroups PC, the NBT name resolution applies the search in the following order of precedence until a name match is found.

NBT searches its internal name cache.
NBT queries the WINS server(s) defined.
A broadcast is issued.
NBT searches the LMHOSTS file.
NBT issues a DNS query for the NetBIOS name in question.

If no match is found, a name-not-found error is returned to NetBIOS.

The Windows Internet Naming Service (WINS)

In essence, a WINS server is a p-node server as defined in RFCs 1001 and 1002. However it is proprietary to Microsoft in implementation. WINS servers have NetBIOS name-to-IP address databases that are built automatically from a variety of sources:

If you are using Windows NT-based DHCP servers, they will inform all of the WINS servers they know about of all the NetBIOS names and IP addresses in their databases.
WINS clients that come up on the network register their NetBIOS names and IP addresses with the WINS servers specified. If a name is duplicated, then it is rejected by the server. This allows the WINS database to be centrally maintained and refreshed by clients scattered around the world.
WINS servers also store local b-node query traffic so that they can answer on behalf of other devices. This means that nodes won't have to resort to broadcasts as often, since the WINS server will respond immediately with the cached information. Note that this oly applies to broadcasts on the local segments that the WINS server(s) is attached to.

Since the WINS servers are populated by so many forms of network activity, they require almost zero administration, and are extremely reliable at the same time. This makes them the best choice for NBT mappings. A single WINS server that all clients point to can be used to enable browsing across an entire world-wide network, since the reliance on broadcasting has all but been eliminated.

Also, clients that do not have WINS software and (and therefore rely on broadcasting) can take advantage of the WINS servers, since the latter will respond to a broadcast on behalf of a remote system. This means that all NBT nodes now can know about any other node that the WINS server knows about, increasing your network's overall reliability.

As an additional note, you can distribute WINS servers to each of your various network segments. This will provide your local Windows for Workgroups PCs with a browsable interface to your entire network.

To enable name resolution with WINS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.

NameServer1=WINS_IP_address

where WINS_IP_address is the IP address of your WINS server. You can also add a secondary WINS server if you want by defining the "NameServer2=" entry.

If you do not want your WINS servers queried before broadcasts are issued, you can change the search order by adding the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. You MUST have a NameServerX entry defined before you set this flag. Otherwise, you will receive name resolution errors.

NodeType=4

For additional information about the NodeType= flag, read the section titled Changing The Search Order below.

Configuring Windows for Workgroups as a WINS Proxy Server

In the previous section we told you that you must have a WINS server on every segment of your network in order for users to browse network-wide resources and for broadcasts to be resolved by WINS. Well, this is only partially true.

The truth is that you can actually configure your Windows for Workgroups PC to be a WINS "proxy" server that will respond to broadcasts, as well as allow you to browse remote network segments. The functionality is far from perfect, but it does provide some additional functionality that you would not otherwise have if you did not place WINS servers on every segment of your network.

The WINS proxy works by redirecting NetBIOS name queries to a defined WINS server. The Windows for Workgroups WINS proxy then stores the responses into its local NBT cache and responds to any SUBSEQUENT requests for the NetBIOS node name. This entry is held in the cache until it either expires or the cache space is needed for new entries.

To enable WINS proxy server capabilities, add the following line to the [NBT] section of your Windows for Workgroup's SYSTEM.INI file. You MUST have a NameServerX entry defined before you set this flag. Otherwise, you will receive name resolution errors.

EnableProxy=1

The LMHOSTS Database

The LMHOSTS database is a raw text file whose format is functionally identical to the TCP/IP HOSTS file. It contains a numerical IP address, a tab character, and a NetBIOS name (and optionally, a comment). LMHOSTS is read by NBT at startup and designated entries are stored in the NBT name cache. This has the absolutely wonderful effect of eliminating all broadcasts destined for nodes or services that are listed in the LMHOSTS file, since the NBT name-to-address entry is already cached.

Do not confuse the LMHOSTS database with the HOSTS database. Although they are similar in use and structure, they serve two entirely separate purposes. The HOSTS file is a database of TCP/IP host names and their corresponding IP addresses, while the LMHOSTS file is strictly for NetBIOS name to IP address mapping. Typically, the LMHOSTS file only shows a few systems. This does not mean that there are only a few nodes on the network, but that there are only a few remote nodes that must be addressed directly. Simply put, the LMHOSTS file allows NBT to take advantage of both the broadcasting and point-to-point architectures without requiring that a dedicated nameserver be on your LAN. Realizing that the "LM" in "LMHOSTS" stands for "LAN Manager" may make the clarification easier.

To enable name resolution with an LMHOSTS file, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.

LMHostFile=C:\WINDOWS\LMHOSTS.

You will need to use NOTEPAD or some other text editor to actually create the LMHOSTS text file.

A sample entry in the LMHOSTS file might look like this:

192.155.15.10 NWCFTP # NWC's FTP Server

This line simply tells NBT that any NetBIOS queries that are destined for the NetBIOS node TGVFTP are supposed to go to 198.93.23.13. By default, this name would be matched after a broadcast had been issued to the client's local IP broadcast address.

You may also need to define NetBIOS service name mappings. Just as a workstation has a NetBIOS name, so do services such as NetBIOS-based SNA gateways and other workgroup applications. An example of an application entry in the LMHOSTS file might look like the following:

127.1.1.1 SNAGATEWAY # SNA gateay box

This would tell NBT that the service SNAGATEWAY can be located on the host 127.1.1.1. If you had an SNA terminal emulator that needed to connect to the gateway system using the NetBIOS service name of SNAGATEWAY, then NBT would build an IP packet destined for 127.1.1.1 with a NetBIOS datagram in it.

You need to be careful about the entries you put into your LMHOSTS file. If they are not the correct name or IP address, you will obviously not get the benefit you desired. Some of the most common problems come from not providing the exact NetBIOS host name as the destination system sees it. For example, you cannot simply define the hostname of TGVFTP as TGVSERVER. The server service will not understand the request. Other problems arise when you specify the wrong IP address of the destination system. If NBT has a name-to-address mapping available, it will use it. Providing the wrong address will cause very long delays as the timeouts will have to clear before control is returned to your system.

Specifying Odd NetBIOS Names

Since NetBIOS doesn't use port numbers like TCP/IP does, its flat and limited namespace must be capable of supporting a variety of names for each destination system. For example, if you are running an SNA gateway, a licensing server, and a client-server application all on the same system, each of these services must have a unique NetBIOS name that indicates the service itself. The service will not respond if the incoming name does not match the actual service name itself.

Some vendors have gotten fairly creative over the years in assigning these NetBIOS names to their services. Some of them are case-sensitive, while other have gotten into the habit of using hexadecimal characters. While technically this is not a problem in the broadcast-centric nature of NetBIOS LANS of old, it becomes a difficulty when you are working with services running on remote servers.

NetBIOS names can be up to 15 characters in length with a 16th byte reserved for special end-of-name terminators. In order to identify these names, you must enclose the entry in quote marks, like this:

127.1.1.1 "ScrewySvcName" # Weird NetBIOS name

If you have to use a hex character in the name, then you must preface the character with the tag "\0x", like this:

127.1.1.1 "GATEWAY \0x20" # Name with Hex character

The above example would put the hex "20" in the 16th byte of the NetBIOS name.

Preloading Entries into the NBT Cache

Remember that the LMHOSTS file is only consulted after a WINS query and a broadcast have both failed, and that these searches are attempted only if the name is not already in the NBT name cache.

If you wish to add a frequently-used name to the LMHOSTS file, then you would use a tag called #PRE at the end of the line. Note that although the "#" symbol in the LMHOSTS file normally signifies a comment, NBT uses the #PRE string as a flag. This is for backward compatibility with LAN Manager servers that do not support selective preloading. They will ignore the #PRE command because they think it is a comment.

An example of a name-to-address entry that is to be pre-loaded into the NBT cache might look like the following:

192.155.15.10 NWCFTP #PRE # FTP Server

Note that everyting after the last comment tag (the "#") is ignored.

This entry would cause NBT to send a directed query directly to the TGVFTP host whenever it was requested, and a broadcast would not be issued beforehand. This is because the #PRE tag is pre-loading the entry into the NBT cache at system startup.

Specifying Domain Controllers

Whenever a client attempts to log onto a LAN Manager domain, broadcasting is used. Normally, a broadcast message follows the chain of events described above, but where domain controllers are involved, it is sometimes necessary to bypass normal channels. You can tell Windows for Workgroups that it is supposed to attempt domain logins with the hosts that are specified by using the #DOM flag.

In fact, you might want to add #DOM flags for all of the login servers in your domain. Then if the primary domain controller fails, the login request will get sent to the next server listed with a #DOM entry.

To signify that a system is a domain controller, put the #DOM:DOMAIN_NAME flag in the LMHOSTS file as follows, where DOMAIN_NAME is the name of the LAN Manager domain that you wish to login to:

127.1.1.1 MARKETING1 #DOM:MARKETING #Marketing PDC

Note that Windows for Workgroups PCs can NOT login to PathWorks domains at the time of this writing. Although PathWorks is based on LAN Manager, DEC has implemented proprietary mechanisms for logging into PathWorks-based domain controllers. This will not prevent you from connecting to resource on PathWorks servers; it only means that you cannot LOGIN to the domain if you only have PathWorks servers.

Sharing LMHOSTS Files Amongst Systems

Obviously, large networks with many servers and LANs will have a hard time dealing with massive LMHOSTS databases. There are a couple of tricks that can help in this situation. One is to use the #INCLUDE flag. #INCLUDE tells NBT to read not only the local LMHOSTS file, but remote LMHOSTS files as well. This would allow you to point NBT to a shared LMHOSTS file on a departmental server or domain controller. For instance:

#INCLUDE \\MARKETING1\public\lmhosts

In this example, the local PC will incorporate any entries in the remote LMHOSTS file whenever a lookup is needed. Although you can point to as many remote databases as needed, you should keep the list as small as possible. If you do this, make sure to give users at least read-only access to the shared file. Also, never reference drive letters for remote systems, but instead use the UNC names of the share point whenever possible (remember, remote drive letters can change!).

There are other tricks that you can do with the #INCLUDE command. For example, suppose that the MARKETING1 server was down. You would not be able to read the remote LMHOSTS file. You would not want to put multiple #INCLUDE statements for each of the servers in the MARKETING domain, as that would increase your search time with no foreseeable benefit (the data in each file would be the same).

However, by enclosing a block of #INCLUDES with #BEGIN_ALTERNATE and #END_ALTERNATE commands, you can tell NBT to search the first available LMHOSTS file. Thus, if MARKETING1 were down, NBT would search MARKETING2's LMHOSTS file:

#BEGIN_ALTERNATE #INCLUDE \\MARKETING1\public\lmhosts #INCLUDE \\MARKETING2\public\lmhosts #INCLUDE \\MARKETING3\public\lmhosts #END_ALTERNATE

Using Domain Name Service (DNS) Servers

Because of TCP/IP's 32-bit numerical node addressing, it is a truly distributed network protocol capable of spanning huge distances and multiple network segments. Unfortunately, these numbers are awful hard to remember. This is why DNS was invented; it provides a hierachial namespace that maps to IP addresses. Users can reference the host FTP.TGV.COM instead of having to remember that its IP address is 198.93.23.13.

While Microsoft has gone off and developed WINS as a mechanism for building databases that map IP addresses to NetBIOS names, DNS has been around for years, and provides a much more robust mechanism that all applications can use, instead of just NetBIOS apps.

However, the NetBIOS limitations of NBT still apply. The NetBIOS name you are querying for must match the name as registered by the system that owns it. Therefore, it is not possible for you to view the resources on the host FTP.TGV.COM by referencing it with that name. You must refer to it by it's NetBIOS name of TGVFTP.

This severly limits the usefulness of DNS as a NetBIOS name-to-IP address mapping tool. However, it is still very useful for viewing nodes that are in your same TCP/IP domain name. If you had a server called MARKETING1 that was also listed in the DNS under that same name, then you could do away with LMHOSTS and WINS altogether, and just use the existing DNS servers.

To enable name resolution with DNS servers, add the following entry to the [NBT] section of your Windows for Workgroups' SYSTEM.INI file. If the [NBT] section does not exist, create it.

EnableDNS=1

You will then need to create another section in SYSTEM.INI called [DNS], and under that add the following entry:

DNSServers=DNS_IP_address DNS_IP_address

where DNS_IP_address is the IP address of your DNS server. You can add up to two DNS servers in this field.

Changing the Search Order

Perhaps you are on a small isolated LAN segment yet you often communicate with servers at your corporate headquarters. You would want to take advantage of WINS servers that were on the remote LAN, but you would not want ALL of your name queries to go to that host before broadcasts were attempted locally. Instead, you might want to broadcast first, and if that failed then go check the WINS server. This would give you quick connections to the local services and hosts, while guaranteeing name resolutions (via WINS) for remote systems.

To change the WINS and broadcasting search order, you need to define one of the following entries in the [NBT] section of SYSTEM.INI. You MUST have a NameServerX= entry already defined, or else you will get name resolution errors.

NodeType=1; b-node, use broadcasts ONLY NodeType=2; p-node, use WINS servers ONLY NodeType=4; m-node, use broadcasts, then WINS NodeType=8; h-node, use WINS, then broadcasts

Note that if you have defined a NameServerX= entry and have not defined an explicit NodeType= entry, then you are defined as a node type of "8", or an h-node. If you have NOT defined a NameServerX= entry, then you are assumed to be a node type of "1", or a b-node.

The Transport Driver Interface (TDI)

One of the few nice things about NetBIOS is that it is simply an API. It does not rely on any specific underlying protocols to connect systems together. For example, Windows for Workgroups' redirector and server (as well as the NetBIOS applications) just talk to the NetBIOS APIs. These APIs can be provided by any protocol. Windows for Workgroups provides NetBEUI and IPX protocols, both of which have NetBIOS APIs available to them. This would allow you to run your Windows for Workgroups file- and printer-sharing (as well as the NetBIOS applications) over IPX if you wanted to. Other vendors provide other protocols with NetBIOS interfaces. Digital's DECnet for example can be used as a transport for Windows for Workgroups' native networking.

However, all of the systems that wish to communicate with NetBIOS must use the same low-level transport protocol. Otherwise, they would never see each other, and the NetBIOS API would be useless.

In order to provide a consistent interface to these protocols, Windows for Workgroups uses a module called the Transport Driver Interface (TDI). TDI provides a link between NetBIOS and the underlying protocols. Without this interface, the redirector software would need to explicitly understand each of the protocols and their capabilities. Whenever a new protocol was introduced, the redirector would have to be re-written. With TDI, it doesn't have to know anything specifically about any of these protocols. It simply needs to communicate with TDI, which handles the necessary conversion and spoofing needed to make the network software work over the chosen protocol.

The biggest problem with this design is that there must be a virtual protocol for the redirector to communicate with. In the case of LAN Manager derivatives such as Windows for Workgroups, that protocol happens to be NetBIOS, which as we've seen isn't very robust. In order for TCP/IP or IPX to act like NetBIOS, lots of trickery has to occur. You lose a lot of the features that came with the underlying protocols by using a lowest-common-denominator approach such as this.

Summary

NetBIOS is extremely limited, but provides a lowest-common-denominator approach to multi-protocol networking. It's use of names for nodes and services makes it easy to use, and its lack of dependancy on any formal hierarchial addressing mechanisms makes it flexible. You can put NetBIOS on top of just about any protocol, from IPX to DECnet to TCP/IP, and it'll work.

However, all sorts of problems arise when you try to map a flat, non-hierarchial namespace onto a distributed, hierarchial address space. There are several options available to the user however, so it is possible to build a name table that meets just about any requirement.

You can use a text file to store static maps (LMHOSTS), or you can setup a Windows NT server to act as a WINS server, or you can rely on your DNS servers already in place. The more complex sites will likely use all of these mechanisms. That's okay!

Whatever methods you choose to employ, remember that NFS doesn't carry any of these burdens, and has much higer levels of portability and availability. You can get NFS servers for AS/400s, HP-3000s, and just about every other platform in the world. And, you can still use your NetBIOS-based applications if you cannot convert them to IP since NBT provides basic NetBIOS name-to-IP address mapping and is not restricted to LAN Manager-centric computing.