5.1 Datagram Distribution over Routed IP Internetworks

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:

  • A P (or M or H) node sends a datagram to the NBDD.

  • The NBDD consults the NBNS database and gathers the IP addresses of all intended recipients.

  • The NBDD then sends a copy of the message, via unicast UDP datagrams, to each of the IP addresses in the list.

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 Server

Node 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.

graphics/05fig01.gif

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

graphics/alert.gif

Datagrams are not considered reliable. As with the UDP service in an IP network, it is expected that some NetBIOS datagrams may be lost .

By allowing the NBDD to silently discard datagrams, however, the lack of reliability is amplified well beyond what would be expected from simple network packet loss .


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:

  • Unicast datagrams are simply sent to the intended recipient.

  • In B mode, multicast/broadcast datagrams are broadcast on the local LAN.

  • For multicast/broadcast datagrams in P, H, and M modes the NBDD should be queried to see if will relay the datagram.

    • If a positive response is received, then send the datagram to the NBDD for distribution.

    • Else:

      • If the datagram is multicast and the Name Server returned a complete IP list, then send the message via unicast datagrams to each IP in the list.

      • Else, broadcast the datagram on the local subnet and hope that some nodes will receive it.

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.



Implementing CIFS. The Common Internet File System
Implementing CIFS: The Common Internet File System
ISBN: 013047116X
EAN: 2147483647
Year: 2002
Pages: 210

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