This is a good point at which to get up, stretch, make a nice hot cup of tea for yourself, take a soothing bath, play with your cat, go for a long walk in the park, take dance lessons, volunteer in your community, sort and organize your old photographs, or join a United Nations Peace Keeping Force. The Datagram Service was previously described as "the second least well understood aspect of NBT." Guess which bit wins first prize. Scope is an oddity of NBT, not because it was a bad idea (though perhaps it was) but because few have ever bothered to really understand it. In practice this feature is rarely used, in part because it is rarely implemented to its full potential. In the RFCs, the term scope is used as a name for:
...but the last of these is beyond the scope of this discussion, so let's take a closer look at the first two. Scope is explained in RFC 1001, Section 9, which starts off by saying: A "NetBIOS Scope" is the population of computers across which a registered NetBIOS name is known. NetBIOS broadcast and multicast datagram operations must reach the entire extent of the NetBIOS scope. This basically means all nodes connected to the virtual LAN . So, for B nodes the NetBIOS scope consists of all nodes within the local IP broadcast domain that are running NBT. For P nodes, the NetBIOS scope includes all nodes across the routed internetwork that run NBT and share the same NBNS. For an M or H node, the scope is the union of the local broadcast and the NBNS scopes. This is all quite straightforward when all NBT nodes are of the same node type, but strange things can happen when you mix modes, particularly in a routed environment. P & B
P & M
B & M
P, B, & M
We now have a good handle on our first definition of scope: " the set of NetBIOS nodes that participate in a virtual LAN ." What about the second: " an identifier used to distinguish one virtual LAN from another "? (This is a good point at which to get up, stretch, make a nice hot cup of tea for yourself...) Every scope has a name, called the Scope Identifier (Scope ID). The most common Scope ID is the empty string: "" . Indeed, this is the default in Windows, Samba, jCIFS, and every other system encountered so far. The only problem with this name is that it becomes too easy to forget that the Scope ID exists. We have already seen that distinct NetBIOS vLANs can be created by using the behavior of B, P, M, and H nodes to create separate scopes. For example, multiple scopes are defined when multiple independent NBNS's provide service for P nodes. B nodes on separate IP LANs are also in separate scopes, and so on. The Scope ID provides another, more refined mechanism for separating scopes. Think of an IP LAN with a bunch of B nodes. Some of the B nodes have Scope ID DOG , and others have Scope ID CAT . Only members of scope DOG will listen to messages sent with that ID; the cats will ignore messages sent to the dogs. So, even though all of the B nodes are on the same wire, we have two separate scopes. The same applies to P and M nodes. The Scope IDs identify, and separate, virtual NetBIOS LANs. Note, though, that an NBNS will handle requests from any node regardless of scope. A single NBNS server can, therefore, support multiple scopes. Figure 2.5. Multiple named scopes in a broadcast LANNodes with scope ID DOG are in their own virtual NetBIOS LAN. Nodes with scope ID CAT will ignore broadcasts to the DOG scope.
According to RFC 1001/1002, a node may belong to more than one scope. In practice, however, it is much easier to choose a single scope and stick with it. This is particularly true for DOS and Windows systems because NetBIOS itself has no concept of scope. The Scope ID is a feature of NBT, and programs that call the NetBIOS API have no way of telling NBT which scope to use. The RFCs suggest that extensions might be added to NetBIOS to manage scope, but using those extensions would require changes to applications. Further, other NetBIOS transports would not support extensions, which would result in compatibility problems. Confusion Alert
|