Windows Internet Name Service
Windows Internet Name Service |
|
Although name conflicts are normally handled at the time of name registration (see "Client Conflicts Detected During Registration" earlier in this chapter), it is possible for the same name to be registered at two different WINS servers. This would happen if a WINS client registered the same name at a second WINS server before the database from the first WINS server replicated to the second. In this case, WINS resolves the conflict at replication time.
Conflict at replication can be between two unique entries, between a unique entry and a group entry, or between two group entries.
Conflict Between Unique Entries WINS resolves conflicting unique entries according to three factors:
Conflict Between Two Replicas When two replicas conflict, the new replica overwrites the replica in the database, regardless of whether the addresses match or not. The only exception to this rule is if the replica in the database is active and the new replica is a tombstone. If the new replica is a tombstone, the replica in the database does not overwrite the new replica, unless they are both owned by the same WINS server.
Conflict Between an Owned Entry and a Replica with the Same IP Address The replica replaces the database record, unless the database record is active and the replica is a tombstone. In that case, WINS increments the version ID of the database record so that the record is propagated at replication time.
Conflict Between an Owned Entry and a Replica with Different IP Addresses The replica replaces the database record unless the database record is active. If the record is active and the replica is a tombstone, WINS increments the version ID of the database record so that the record can be propagated by replication. If the replica is also active, the server receiving the replica challenges the client that owns the name in the local database to determine whether the client still uses the name. If it does, WINS sends the client node designated in the replica record a name conflict demand, a message that puts the client in a conflict state. This forces the node to place the name in the conflict state. A name in the conflict state is marked and the name is no longer used.
Conflict Between a Unique Entry and a Group Entry When a unique entry and a group entry conflict, WINS keeps the group entry. If the WINS server owns the unique entry and the entry is not in the released or tombstone state, the WINS server asks the client named in the unique entry to release the name.
Conflict Between Two Special Group Entries The replica replaces the database record unless the database record is active. If the record is active, WINS increments its version ID so that the record is propagated at replication time. If the replica is also active, the WINS server updates the member list of the database record with any new members from the replica. If the list of active members grows to more than 25, the extra members are not added but are dropped silently.
Conflict Involving a Multihomed Record If a multihomed replica conflicts with a tombstone or released entry in the database, WINS replaces the entry in the database with the replica, unless the entry is a normal group and is in the released state. This is no different from the other scenarios in which a single-address entry conflicts with a released normal group entry.
If a multihomed replica in the tombstone state conflicts with an active database entry owned by the same server as that of the multihomed replica, the database entry is replaced. If the active database entry is a replica owned by a different owner, WINS does not replace the database entry. If the active database entry is owned by the local WINS server and is a unique entry, the WINS server increments the version ID of the database record to prompt propagation.
If an active multihomed replica conflicts with an active, unique, multihomed replica in the local database with the same owner, the database entry is replaced. If the owner is different, it is not replaced. If the entry in the database is owned by the local WINS server, and if the members of the record (a single member in the case of a unique record) is a subset of the members in the replica, WINS changes the time stamp of the database record and increments its version ID to force propagation. If the members of the replica are not a subset, the addresses in the database record are challenged. If all challenges succeed—that is, the clients challenged do not respond to any challenge—the database record is replaced. If at least one challenge fails, WINS tells the client to release the name from all addresses prior to replacing the database record with the replica.
If a multihomed replica conflicts with an active group entry in the database, WINS increments the version ID of the entry in the database to cause propagation.
If a single-address replica conflicts with an inactive multihomed record in the database, WINS replaces the database record with the replica. If the replica conflicts with an active multihomed entry in the database owned by the same owner, WINS replaces the database record with the replica. If the multihomed entry in the database is a replica owned by a different server, WINS does not replace it. If, however, the multihomed entry is owned by the local WINS server, and the pulled replica is a unique record, then WINS issues a challenge to the clients using the addresses in the multihomed record. If all challenges succeed, WINS replaces the database record. If at least one challenge fails, WINS sends the addresses in the database record requests for the name, and then the database record is updated. Note that the address in the unique replica, if present in the member list, is ignored in the above situation.