WINS Client Behavior

This section looks at how WINS clients react to various basic scenarios, including:

• Daily startup of the WINS client.

• Plugging into a different subnet.

• Prolonged shutdowns.

• Joining two WINS systems.

Daily Startup

An active WINS client name registration in a WINS server database is replicated to all of the push partners of that server. A push partner is a WINS server that sends data to other servers to start replication. After some time, the active name registration is replicated to all WINS servers on the network.

When the WINS client is turned off at the end of the day, it releases the name. With the default extinction interval, it does not enter the extinct state during the night, and therefore it is not replicated again that night. When the computer is started the next morning, the WINS client registers the name again with the WINS server and receives a new version ID. This new, active name registration entry is replicated to the pull partners of the WINS server as on the previous day. A pull partner is a WINS server that requests data to be sent to it from other servers.

The number of name registration entries replicated each day is roughly equivalent to the number of computers started each day multiplied by the number of NetBIOS names registered by each computer.

On large networks (50,000 or more computers), the biggest traffic load may be the name registration requests generated when WINS clients start on the network. Fortunately, the difference in time zones in large enterprise networks provides some distribution of this WINS client startup load.

Plugging Into a Different Subnet

A roaming user who powers down a computer and then moves it to a different subnet with another primary WINS server generates name challenge traffic. Typically the name registration request is answered with the wait for acknowledgment message. Then, assuming the active entry was replicated, the new WINS server generates a name query packet to challenge the IP address currently in its database for the name. Because the computer that registered that address is no longer active on that subnet and no longer using that IP address, it makes no reply. Just to be sure that the lack of response is not a fluke, the WINS server repeats the query three times.

Usually the name challenge never travels over the subnet that the computer has left because the ARP request fails. However, the challenge message does travel on the subnet of the new WINS server and the links between the routers. The WINS server assigns a new version ID to the new entry so that it will replicate from its new owner to other WINS servers.

Prolonged Shutdowns

Some computers do not start up for a period longer than the verification interval . The verification interval is the interval after which the WINS server must verify that any old names that it does not own that are in its database are still active. The WINS server does not delete replica entries for these computers because the owned entries never become extinct, remaining active in the database. A computer that occasionally starts up refreshes all of its replica entries by giving each of them a new version ID. This new version ID prompts replication of the replicas to other WINS databases on the network.

Sometimes the computer stays shut down for an extended period, and therefore its replicas are not refreshed for a period longer than the verification interval. When a WINS server has such an old replica, it tries to verify this entry with the owning WINS server. If the owning server does not find this entry, it is removed from the database of the verifying server. If the entry is verified, its new state is recorded.

Joining Two WINS Systems

When two organizations merge, their computer systems must merge as well, including their WINS systems. When merging two WINS systems, the initial replication load and the potential for conflicting NetBIOS names might present problems. After a WINS server from one system is connected to a WINS server from the other, they eventually replicate their records with each other; because they have no shared records, the whole database from each system must be replicated. Then their replication partners copy the new entries, until all the databases have converged.

To avoid making this process any more difficult, merge the systems and force replication at a time when the connecting WAN links are more or less idle. When the databases contain conflicting names, the conflicts are resolved, which may result in other traffic. This process is described in "Client Conflicts Detected During Registration" earlier in this chapter.

Note

The users of computers with conflicting names will probably call the help desk when they get the "duplicate name" messages and their computers refuse to open new sessions.