Implementing CIFS: The Common Internet File System
| If a tree falls in the forest, and no one is there to hear it... Let's drill home this key concept one more time: NBT provides a set of services which combine to create a virtual NetBIOS LAN over TCP/UPD/IP transport. This would be a senseless thing to do except for the fact that lots of software uses (or used to use) the NetBIOS API. The whole point is to maintain the form and function of the API while completely replacing the guts and machinery which lie beneath . This point gets lost, however, when we deal with systems that are not derived from MS-DOS and have no use for NetBIOS itself. On these systems we work directly with the guts of NBT and, therefore, are easily confused by the odd behavior of the machinery. So, to provide a little context, here are the four NetBIOS API functions which the Datagram Service was designed to support:
Let's start by looking at the two Send Datagram functions. These two API calls provide us with three transmission options: unicast, multicast, and broadcast. Here's how they work: Send Specific Datagram This function requires a NetBIOS name as a parameter.
Send Broadcast Datagram This function does not accept a NetBIOS name. Broadcast datagrams are sent the length and breadth of the NetBIOS LAN, and picked up by any node that is listening. That was easy. Now let's look at what happens when we map those functions onto UDP/IP at the NBT layer... Send Specific Datagram A NAME QUERY REQUEST is issued to discover whether the destination name is a unique or group name.
Send Broadcast Datagram The wildcard name (with the sender's Scope ID appended) is used as the destination name.
As you can see from the description, unicast datagrams are easy, B mode is easy, but handling multicast or broadcast in P, or M, or H mode is a bit more complicated. We'll give that topic a section heading all its own, just to show that it is a fairly hefty chunk of tofu. |