The N et B IOS D atagram D istribution Server (NBDD) compliments the NBNS. It assists in extending the virtual NetBIOS LAN across a routed IP internetwork by relaying multicast and broadcast NetBIOS datagrams to nodes on remote subnets. The NBDD's job is to make sure that the datagrams get to where they're supposed to go. It works something like a lawn sprinkler one input leads to a spray of outputs. Here's what happens:
That seems simple enough, but we claimed earlier that the Datagram Service is the second least well understood aspect of NBT. What are we missing? A closer inspection reveals an obvious problem. If the number of destination nodes is large, a whole bigbunch of traffic will be generated possibly enough to bring the NBT virtual LAN to its knees (which might really, really annoy people). The NBDD design will work well enough for small, trusted networks but it simply does not scale. Another problem is that RFC 1001 offers a loophole for implementors: the NBDD is permitted to silently ignore requests to relay datagrams. If, for any reason (including laziness on the implementor's part) the NBDD will not or can not relay a datagram, it simply discards the message without sending any sort of error message back to the originating node. Figure 5.1. The Datagram Distribution ServerNode MICK wants to send a message to all members of group LINDISFARNE , but the NetBIOS LAN is distributed across a routed IP internetwork. MICK sends the datagram to the NBDD which relays the message to all group members.
This loophole might make the NBDD so unreliable as to be useless, except that the Datagram Service also supports a query operation that allows the client to ask the NBDD whether or not it will relay a message. If the NBDD answers the query with a "yes," then the client can send the datagram with the assurance that it will be relayed to all intended recipients. A negative reply means that the NBDD will not relay the message. Reminder Alert
One more monkey -wrench to throw into the works... Given a multicast (not broadcast) datagram, if the NBDD will not relay the message, the client can give it another shot. The client has already performed a Name Service NAME QUERY REQUEST operation, and received a NAME QUERY RESPONSE from the NBNS. It did this to determine that the destination name was, in fact, a group name rather than a unique name. If the NBNS is RFC-compliant, then the NAME QUERY RESPONSE will contain a list of all the IP addresses of the group members. If the NBDD won't relay the message, then the client can unicast the datagram to each entry in the list. To summarize:
Confused? Don't be surprised if you are. It isn't a pretty system... and it gets worse. Because of the potential network problems and the awkwardness of the design, very few implementations even try to match the RFC specification. Unfortunately, no one has come up with a better solution... which means that what actually exists in the wild is worse than what was just described. |