NetBIOS over TCP/IP (NetBT) is the session-layer network service that performs name-to-IP address mapping for name resolution. In the SunLink Server program, NetBT is implemented through WINS and broadcast name resolution. The two most important aspects of the related naming activities are registration and resolution:
Registration is the process used to register a unique name for each computer (node) on the network. A computer typically registers itself when it starts.
Resolution is the process used to determine the specific address for a computer name.
RFCs 1001 and 1002 specify how NetBIOS should be implemented over TCP/IP and define the name resolution modes.
Defined within NetBT are modes that specify how network resources are identified and accessed. The NetBT modes supported by SunLink Server software are:
b-node - Uses broadcast messages to resolve names
h-node - First uses another type of node for name queries and then b-node if the name service is unavailable or if the name is not registered in the database
The RFCs refer to a NetBIOS Name Server (NBNS). WINS is an enhanced NBNS.
The two most common node types for Windows client computers are b-node and h-node.
For DHCP users, the node type may be assigned by the DHCP server (depending on how the client has been configured). When WINS servers are in place on the network, NetBT resolves names on a client computer by communicating with the WINS server. When WINS servers are not in place, NetBT uses b-node broadcast messages to resolve names. NetBT also can use LMHOSTS files for name resolution, depending on how TCP/IP is configured on a particular computer.
SunLink Server software can respond to b-node and h-node NetBT modes.
The b-node mode uses broadcasts for name registration and resolution. For example, if CLIENT_PC1 wants to communicate with CLIENT_PC2, it will broadcast to all machines that it is looking for CLIENT_PC2 and then will wait a specified time for CLIENT_PC2 to respond.
The b-node mode has two major problems:
In a large environment, it loads the network with broadcasts.
Typically, routers do not forward broadcasts, so computers that are on opposite sides of a router will never hear the requests.
The h-node mode solves the most significant problems associated with broadcast messages and with routed-environment operations. It is a combination of b-node and another node type that uses broadcast messages as a last effort. If the WINS server is down--making broadcast messages a necessity--the computer continues to poll the WINS server until it can be reached again. The h-node also can be configured to use the LMHOSTS file after broadcast name resolution fails.
No broadcast messages are generated if the WINS server is running, and computers can be on opposite sides of routers. If the WINS server is down, b-node is used, allowing computers on the same side of a router to continue to operate as usual.
For Microsoft TCP/IP users who configure TCP/IP manually, h-node is used by default unless the user does not specify addresses for WINS servers when configuring TCP/IP.
Another variation, known as modified b-node, is used in SunLink Server networks to allow messages to go across routers. The modified b-node does not use a WINS server. In this mode, b-node uses a list of computers and addresses stored in an LMHOSTS file. If a b-node attempt fails, the system looks in LMHOSTS to find a name and then uses the associated address to cross the router. However, each computer must have this list, which creates an administrative burden in maintaining and distributing the list.
Windows for Workgroups 3.11 uses a modified b-node system. Windows NT uses this method if WINS servers are not used on the network. In Windows NT, some extensions have been added to this file to make it easier to manage--but modified b-node is not an ideal solution.