WINS Database Files

The format of the WINS database increases the speed and efficiency of data storage by writing current transactions to log files rather than to the database directly. Therefore, the most current view of the state of the WINS database requires examination of the database plus any transactions in the log files. These files are also used for recovery; if the service fails (for example, due to a power failure), the log files can recreate the correct state of the WINS database.

Log files are always about 1 megabyte in size; however, they can grow quickly on a very busy WINS server. When a WINS server reaches the maximum size of its current log file, it creates another log file.

The effective size of the database of each connected WINS server is roughly identical. Each database has the same number of entries, neglecting latencies, and the size of the database is proportional to the number of entries. Unique entries typically occupy 42 bytes (they require no scope ID). Internet Group entries might occupy as many as 25 addresses and, therefore, more bytes. The real size might be much larger because unused space is only reclaimed efficiently by compacting.

The name–to–IP address mapping table stores NetBIOS names and the IP addresses currently assigned to them. The entries in this table are created from NetBIOS name registration requests received over TCP/IP nodes and from replicas received from other WINS servers. A clustered index on the name field enables quick retrieval of records required for name queries. A clustered index is an index in which the logical or indexed order of the key values is the same as the physical stored order of the corresponding rows that exist in a table. A primary index is built from the concatenation of the owner ID and version ID fields, and stored in ascending order. This allows quick access to records falling within ranges of version IDs for a particular owner.

The IP address–to–owner ID mapping table contains a row for each WINS server that has entries in the name–to–IP address mapping table. Rows contain the IP address of WINS servers and their identifier as stored in the owner ID field of the entries that this server owns.

Timers

The WINS database records are governed by four configurable timer values:

• Renewal interval

• Extinction interval

• Extinction timeout

• Verification interval

Microsoft has chosen the defaults for these four values with care and, in general, they should not be modified. They keep the level of network traffic and the load on WINS servers at a minimum. They represent the best tradeoff, considering the various configurations in which WINS servers might be deployed, between these goals and minimizing the window during which the databases remain out of sync. Considerations such as long weekends, avoidance of unnecessary replication traffic, ability to handle a large number of clients quickly under worst-case scenarios—as well as tradeoffs between removing clutter quickly and retaining entries to ensure replication—have been factored into the determination of these intervals.

Figure 7.8 Name Record Configuration Dialog Box

These four values are listed in Table 7.7, and are described in more detail in this section. They are configured in the dialog box shown in Figure 7.8.

Table 7.7 WINS Server Timers

Renewal Interval

The renewal interval is also known as the name refresh timeout, or the Time To Live (TTL). When a name is registered with the WINS server, the database entry is time stamped with the sum of the current time and the renewal interval. A client must refresh its name with the WINS server within this interval or the name is released. When a name is released, either by timing out or by the explicit release of the name by the client, no action is taken other than changing the entry to the released state and time stamping the entry with the sum of the current time and the extinction interval. This change is not replicated to other WINS servers. When a name is in the released state and a new registration comes in with a different address, the name can be immediately given to the new client without challenge because it is known that the old client is no longer using the name. The default renewal interval is six days.

Extinction Interval

The extinction interval is also known as the name age timeout and the tombstone interval. This is the interval at which released names enter the tombstone state. At this time, the entry is time stamped with the sum of the current time and the extinction timeout; and the entry's version ID is updated, ensuring that this information is propagated to all WINS servers at the next replication.

When tombstone entries are created, they are time stamped with the sum of the current time and the extinction timeout at the pulling WINS server. The default extinction interval is based on renewal and replication times. This is typically six days in Windows 2000.

Extinction Timeout

The extinction timeout is also known as the tombstone timeout. Tombstone records older than the extinction timeout are removed from the database. As noted earlier, manual extinction is available in Windows 2000 from the WINS console. The default extinction timeout is six days.

Verification Interval

Replication should ensure that the databases stay synchronized. However, under certain abnormal conditions, names no longer in use could remain in the database, creating database clutter. For example, if a tombstone record is removed before being replicated, the active state of the record in the replica databases never changes. This could happen if the replication partner was not reachable during the extinction timeout period.

When an active entry is replicated, it is time stamped with the sum of the current time and the verification interval on the pulling WINS server. If, at scavenge time, WINS finds records older than the verification interval, WINS sends a query to the WINS server that owns that name, asking if the version ID is still valid. If the owning WINS server responds negatively (invalid record), the record is removed. If the owning WINS server sends a positive response (valid record), the time stamp is updated. If the WINS server cannot be contacted, the entries are left until the next verification interval or until the administrator triggers scavenging. No records are removed if the owning WINS server cannot be contacted. The default verification interval is 24 days.

Server Clocks

The replication and scavenging algorithms rely on a reasonably consistent system clock. Of course, setting the system clock forward or backward affects these algorithms. However, because the time stamps are always entered locally, the WINS servers do not need to be time-synchronized. As long as the time is consistent on each server, the intervals and timers function correctly.