Main Page>Table of contents>Overview of NetBIOS-over-TCP/IP>NetBIOS 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 networks of minor complexity, 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.