Microsoft NetBIOS

As we mentioned, NetBIOS API implementations exist for numerous network protocols, making the interface protocol-independent. In other words, if you develop your application according to the NetBIOS specification, the application can run over TCP/IP, NetBEUI, or even IPX/SPX. This is a useful feature because it allows a well-written NetBIOS application to run on almost any machine, regardless of the machine's physical network. However, there are a few considerations. For two NetBIOS applications to communicate with each other over the network, they must be running on workstations that have at least one transport protocol in common. For example, if Joe's machine has only TCP/IP installed and Mary's machine has only NetBEUI, NetBIOS applications on Joe's machine won't be able to communicate with applications on Mary's machine.

Additionally, only certain protocols implement a NetBIOS interface. Microsoft TCP/IP and NetBEUI offer a NetBIOS interface by default; however, IPX/SPX does not. Therefore Microsoft provides a version of IPX/SPX that does implement the interface, which is something to keep in mind when designing a network. When installing protocols, the NetBIOS-capable IPX/SPX protocol usually states something to that effect. For example, Windows 2000 offers the protocol NWLink IPX/SPX/NetBIOS Compatible Transport Protocol. In Windows 95 and Windows 98, the IPX/SPX protocol Properties dialog box has a check box that enables NetBIOS over IPX/SPX.

One other important bit of information is that NetBEUI is not a routable protocol. If there is a router between the client machine and the server machine, applications on those machines will not be able to communicate. The router will drop the packets as it receives them. TCP/IP and IPX/SPX are both routable protocols and do not suffer from this limitation. Keep in mind that if you plan to use NetBIOS heavily, you might want to build your networks with at least one of the routable transport protocols. For more information on protocol characteristics and considerations, see Chapter 6.

LANA Numbers

You might be wondering how transport protocols relate to NetBIOS from the programming aspect. The answer is LAN Adapter (LANA) numbers, which are the key to understanding NetBIOS. In the original implementations of NetBIOS, each physical network card was assigned a unique value: a LANA number. Under Win32 this becomes a bit more problematic, as a workstation can have multiple network protocols installed as well as multiple network interface cards.

A LANA number corresponds to the unique pairings of network adapter with transport protocol. For example, if a workstation has two network cards and two NetBIOS-capable transports (such as TCP/IP and NetBEUI), there will be four LANA numbers. The numbers might correspond to the pairings as follows:

  1. TCP/IP—Network Card 1
  2. NetBEUI—Network Card 1
  3. TCP/IP—Network Card 2
  4. NetBEUI—Network Card 2

Generally, LANA numbers range from 0 to 9, and the operating system assigns them in no particular order except for LANA 0, which has a special connotation. LANA 0 is the "default" LANA. When NetBIOS first became available, many applications were hardcoded to work only on LANA 0—at that time, most operating systems supported a single LANA number. For the purpose of backward compatibility, you can manually assign LANA 0 to a particular protocol.

In Windows 95 and Windows 98, you can access a network protocol's Properties dialog box through the Network icon in the Control Panel. Select the Configuration tab in the Network dialog box, select a network protocol from the network component list, and click the Properties button. The Advanced tab of the Properties dialog box for each NetBIOS-capable protocol has a Set This Protocol To Be The Default Protocol check box. Selecting the check box rearranges the bindings of the protocols so that the default protocol is assigned LANA 0. Only one protocol can have this check box selected at any given time. Because of the plug-and-play nature of Windows 95 and Windows 98, there is no other way to explicitly set the numbering order for protocols.

Windows NT 4 allows greater flexibility in setting up NetBIOS. The Services tab of the Network dialog box allows you to select NetBIOS Interface from the Network Services list box and click Properties. The NetBIOS Configuration dialog box that appears allows you to specifically assign LANA numbers to each pairing of network interface with transport protocol. In this dialog box, each network interface is referred to by its driver name; the protocol names are a bit cryptic. Figure 1-2 shows the NetBIOS Configuration dialog box. By clicking the Edit button, you can manually assign the LANA numbers to individual protocols. Windows 2000 also allows you to specifically assign LANA numbers. From the Control Panel, click the Network And Dial-up Connections icon. Then select Advanced Settings from the Advanced menu, and click the LANA numbers tab in the Advanced Settings dialog box.

When developing a robust NetBIOS application, always write code that can handle connections on any LANA number. For example, suppose Mary writes a NetBIOS server application that listens for clients on LANA 2. On Mary's machine, LANA 2 happens to correspond to TCP/IP. Then Joe decides to write a client application to interface with Mary's server, so he decides his application will connect over LANA 2 on his workstation; however, LANA 2 on Joe's machine is NetBEUI. Neither application will ever be able to communicate with the other, even though they both have TCP/IP and NetBEUI installed. To remedy this discrepancy in protocols, Mary's server application should listen for client connections on every available LANA number on Mary's workstation. Likewise, Joe's client application should attempt a connection on each LANA number available on his machine. This way, Mary and Joe can ensure that their applications have the highest degree of success in communication. Of course, writing code that can handle connections on any LANA number does not mean the code will work 100 percent of the time. There remains the case of two machines not having a single common protocol.

Figure 1-2. NetBIOS Configuration dialog box. This machine is multihomed with two network cards and three transport protocols: TCP/IP (NetBT), NetBEUI (Nbf), and IPX/SPX (NwlnkNb).

NetBIOS Names

Now that we know what LANA numbers are, let's move on to NetBIOS names. A process—or application, if you prefer—registers a name on each LANA number that it wants to communicate with. A NetBIOS name is 16 characters long, with the 16th character reserved for special use. When adding a name to the name table, you should initialize the name buffer to spaces. In the Win32 environment, each process has a NetBIOS name table for each available LANA number. Adding a name to LANA 0 means that your application is available to clients connecting on your LANA 0 only. The maximum number of names that can be added to each LANA is 254, with numbering from 1 to 254 (0 and 255 are reserved for the system); however, each operating system sets a default maximum number less than 254 that you can change when resetting each LANA number.

Additionally, there are two types of NetBIOS names: unique and group. A unique name is exactly that: no other process on the network can have that name registered. If another machine does have the name registered, you will receive a duplicate name error. As you might know, machine names in Microsoft networks are NetBIOS names. When a machine boots, it registers its name with the local Windows Internet Naming Server (WINS) server, which reports an error if another machine has that name in use. A WINS server maintains a list of all registered NetBIOS names. Additionally, protocol-specific information can be kept along with the name. For example, on TCP/IP networks, WINS maintains a pairing of NetBIOS names with the IP address that registered the name. If the network is configured without a WINS server, machines perform duplicate name checking by broadcasting a message on the network. If no other machine challenges the message, the network allows the sender to use that name. On the other hand, group names are used to send data to multiple recipients or, conversely, receive data destined for multiple recipients. A group name need not be unique. Group names are used for multicast data transmissions.

The 16th character in NetBIOS names distinguishes most Microsoft networking services. Various networking service and group names are registered with a WINS server by direct name registration from WINS-enabled computers or by broadcast on the local subnet by non-WINS-enabled computers. The Nbtstat command is a utility that you can use to obtain information about NetBIOS names that are registered on the local (or remote) computer. In the example shown in Table 1-1, the Nbtstat -n command produced this list of registered NetBIOS names for user "Davemac" logged on to a computer configured as a primary domain controller and running Windows NT Server with Internet Information Server.

Table 1-1. NetBIOS name table

Name 16th Byte Name Type Service
DAVEMAC1 <00> UNIQUE Workstation service name
DAVEMAC1 <20> UNIQUE Server services name
DAVEMACD <00> GROUP Domain name
DAVEMACD <1C> GROUP Domain controller name
DAVEMACD <1B> UNIQUE Master browser name
DAVEMAC1 <03> UNIQUE Messenger name
Inet~Services <1C> GROUP Internet Information Server group name
IS~DAVEMAC1 <00> UNIQUE Internet Information Server unique name
DAVEMAC1+++++++ <BF> UNIQUE Network monitor name

The Nbtstat command is installed only when TCP/IP is an installed protocol. This utility can also query name tables of remote machines by using the -a parameter followed by the remote machine's name, or by using the -A parameter followed by the remote machine's IP address.

Table 1-2 lists the default 16th byte value appended to unique NetBIOS computer names by various Microsoft networking services.

Table 1-2. Unique name qualifiers

16th Byte Identifies
<00> Workstation service name. In general, this is the NetBIOS computer name.
<03> Messenger service name used when receiving and sending messages. This is the name that is registered with the WINS server as the messenger service on the WINS client and is usually appended to the computer name and to the name of the user currently logged on to the computer.
<1B> Domain master browser name. This name identifies the primary domain controller and indicates which clients and other browsers to use to contact the domain master browser.
<06> Remote Access Service (RAS) server service.
<1F> Network Dynamic Data Exchange (NetDDE) service.
<20> Server service name used to provide share points for file sharing.
<21> RAS client.
<BE> Network Monitor Agent.
<BF> Network Monitor utility.

Table 1-3 lists the default 16th byte character appended to commonly used NetBIOS group names.

So many qualifiers might seem overwhelming. Think of them as a reference. You probably shouldn't be using them in your NetBIOS names. To prevent accidental name collisions with your NetBIOS names, you probably want to avoid using the unique name qualifiers. You should be even more careful with group names—no error will be generated if your name collides with an existing group name. When this happens you might start receiving data intended for someone else.

NetBIOS Features

NetBIOS offers both connection-oriented services and connectionless (datagram) services. A connection-oriented service allows two entities to establish a session, or virtual circuit, between them. A session is a two-way communication stream whereby each entity can send the other messages. Session-oriented services provide guaranteed delivery of any data flowing between the two endpoints. In session-oriented services, a server usually registers itself under a certain known name. Clients look for this name in order to communicate with the server. In NetBIOS terms, the server process adds its name to the name table for each LANA it wants to communicate over. Clients on other machines resolve a service name to a machine name and then ask to connect to the server process. As you can see, a few steps are necessary to establish this circuit, and some overhead is involved in first setting up the connection. Session-oriented communication guarantees reliability and packet ordering; however, it is still message-based. That is, if a connected client issues a read command, the server will return only one packet of data on the stream, even if the client supplies a buffer large enough for several packets.

Table 1-3. Group name qualifiers

16th Byte Identifies
<1C> A domain group name that contains a list of the specific addresses of computers that have registered the domain name. The domain controller registers this name. WINS treats this as a domain group: each member of the group must renew its name individually or be released. The domain group is limited to 25 names. When a static 1C name is replicated that clashes with a dynamic 1C name on another WINS server, a union of the members is added, and the record is marked as static. If the record is static, members of the group do not have to renew their IP addresses.
<1D> The master browser name used by clients to access the master browser. There is one master browser on a subnet. WINS servers return a positive response to domain name registrations but do not store the domain name in their databases. If a computer sends a domain name query to the WINS server, the WINS server returns a negative response. If the computer that sent the domain name query is configured as h-node or m-node, it will then broadcast the name query to resolve the name. The node type refers to how the client attempts to resolve a name. Clients configured for bnode resolution send broadcast packets to advertise and resolve NetBIOS names. The p-node resolution uses point-to-point communication to a WINS server. The m-node resolution is a mix of b-node and p-node in which b-node is used first and then, if necessary, p-node is used. The last resolution method is h-node, or hybrid node. It always attempts to use p-node registration and resolution first, falling back on b-node only upon failure. Windows installations default to h-node.
<1E> A normal group name. Browsers can broadcast to this name and listen on it to elect a master browser. These broadcasts are for the local subnet and should not cross routers.
<20> An Internet group name. This type of name is registered with WINS servers to identify groups of computers for administrative purposes. For example, "printersg" could be a registered group name used to identify an administrative group of print servers.
_MSBROWSE_ Instead of a single appended 16th character, "_MSBROWSE_" is appended to a domain name and broadcast on the local subnet to announce the domain to other master browsers.

On the other hand, there are also connectionless, or datagram, services. In this case a server does register itself under a particular name, but the client simply gathers data and sends it to the network without setting up any connection beforehand. The client addresses the data to the NetBIOS name of the server process. This type of service offers no guarantees, but it offers better performance than connection-oriented services. Furthermore, with datagram services no overhead is involved in setting up a connection. For example, a client might quickly send thousands of bytes of data to a server that crashed two days earlier. The client will never receive any error notifications unless it relies on responses from the server (in which case, it could deduce that something was amiss after not receiving any response for some period of time). Datagram services do not guarantee reliability, nor do they preserve message order.



Network Programming for Microsoft Windows
Linux Server Hacks, Volume Two: Tips & Tools for Connecting, Monitoring, and Troubleshooting
ISBN: 735615799
EAN: 2147483647
Year: 1998
Pages: 159

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net