4.1 NetBIOS Registration Example

Consider a multihomed node A with an Internet host name of "EXAMPLE" supporting the extensions defined herein.

Multihomed node example

Figure 1: Multihomed node example

  1. At startup, Node A uses DHCP on each interface. On interface 1, it gets a NetBIOS over TCP/IP Node Type Option indicating it is to be an H node. From interface 2, it gets no DHCP response, but defaults to B node behavior. Hence when it decides to be a B node based on interface 2, it overwrites its Node Type to be the type from interface 2.

  2. Later, an application wants to publish a NetBIOS name and chooses to use the convention defined in section 1.8. The application chooses a NetBIOS suffix of 0x19, and constructs the NetBIOS name of "EXAMPLE", padded with spaces to 15 bytes, and puts the NetBIOS suffix in the 16th byte, resulting in the following hexadecimal bytes: [0x45, 0x58, 0x41, 0x4D, 0x50, 0x4C, 0x45, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x19]. In this example, this is referred to as the name EXAMPLE. The application asks NetBIOS to register the name EXAMPLE on interface 1, and NetBIOS sends a NAME REGISTRATION REQUEST to the first NBNS learned on that interface.

    In this example, the NBNS discovers that another node already has the name registered and so the NBNS responds with a NEGATIVE NAME REGISTRATION RESPONSE.

    The node receives the response, the name EXAMPLE is not added to the Local Name Table, and a failure is returned to the application.

  3. The application then tries to register the NetBIOS name EXAMPLE on interface 2.

    No NBNSs are known on interface 2, so the registration succeeds.

    The name EXAMPLE is then added to the Local Name Table, with interface 2 in the Interface List.

  4. Later, another application tries to register the NetBIOS name EXAMPLE on interface 2. The name is already registered on that interface, so a success is immediately returned to the application.

  5. Later, another application tries to register EXAMPLE on interface 1.

    The NBNS again responds with a NEGATIVE NAME REGISTRATION RESPONSE causing registration to again fail on subnet 1.

    This time because an entry already exists in the Local Name Table, interface 1 is added to the Interface List for the name EXAMPLE in the Local Name Table, with the Conflict Detected Flag set.

  6. Later, another application tries to register EXAMPLE on interface 1.

    Registration fails immediately (without sending any request) because an entry already exists with the Conflict Detected Flag set for some interface (interface 1).

  7. Later, another application tries to register EXAMPLE on interface 2.

    Registration fails immediately (without sending any request) because the name is already registered on Node A.

  8. Later, a NAME QUERY is received on interface 2 for the name EXAMPLE.

    The node replies with a POSITIVE NAME QUERY RESPONSE because the Conflict Detected Flag is clear for that interface.

  9. Later, a broadcast NAME QUERY is received on interface 1 for the name EXAMPLE.

    No response is sent because the Conflict Detected Flag is set for that interface.

  10. Later, a unicast NAME QUERY is received on interface 1 for the name EXAMPLE.

    The node replies with a NEGATIVE NAME QUERY RESPONSE to indicate that the name is in the Local Name Table but is in conflict.

  11. Later, a NAME REGISTRATION REQUEST is received for the name EXAMPLE on interface 1.

    No response is sent because the Conflict Detected Flag is set on some interface (interface 1).

  12. Later, a NAME REGISTRATION REQUEST is received for the name EXAMPLE on interface 2.

    The node replies with a POSITIVE NAME QUERY RESPONSE because the Conflict Detected Flag is clear for the interface (interface 2).

  13. Later, an address change occurs on interface 1 after the conflicting entry has been removed from the NBNS by an administrator.

    Node A tries to reregister the name EXAMPLE on interface 1 by sending a new NAME REGISTRATION REQUEST.

    This time registration succeeds, and the server replies with a POSITIVE NAME REGISTRATION RESPONSE.

    The node receives the response and clears the Conflict Detected Flag for interface 1.

  14. Later, a NAME REGISTRATION REQUEST is received for the name EXAMPLE on interface 1.

    The node replies with a NEGATIVE NAME REGISTRATION RESPONSE because the name is in the Local Name Table and no Conflict Detected Flag is set.

  15. Later, a NAME REGISTRATION REQUEST is received for the name EXAMPLE on interface 2.

    The node replies with a NEGATIVE NAME REGISTRATION RESPONSE because the name is in the Local Name Table and no Conflict Detected Flag is set.