다음을 통해 공유

Pull partners

  • 아티클

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 8 Beta

Pull partners

A pull partner is a WINS server that pulls or requests replication of updated WINS database entries from other WINS servers (those configured to use it as a push partner) at a configured interval. This is done by requesting entries with a higher version ID than the last entry received from its configured partner.

You can enable WINS to pull (request) a replication with its configured partners when one of the following events occurs:

  • When the WINS server starts.

  • When a set amount of time has elapsed.

The amount of time between pull replications is indicated in the Replication interval, which can be specified either globally for all pull partners or individually for specific partners. When the time has elapsed for each interval, WINS sends a pull replication trigger to its pull partners. The partners can then respond with incremental changes, if any have been made since the last time replication occurred.

To configure which of these options WINS uses, you need to configure pull parameters, either the default parameters that the server uses for all pull partners or the parameters in effect for a specific partner. For more information, see Modify pull partner properties.

Additionally, you have the administrative option of manually sending a pull replication trigger to another pull partner of the selected WINS server. For more information, see Send a replication trigger to a selected partner.

How WINS determines which entries to pull replicate

Because push-based replication uses notification, it does not transfer any records until a subsequent pull trigger is returned by the notified partner. For this reason, pull replication can be viewed as the single process used to replicate WINS data between servers.

All WINS servers maintain an internal mapping table--an owner-version mapping table--which is used to complete the replication process. This table is built dynamically at startup by the server and is held in memory.

The owner-version mapping table contains the following:

  1. An owner ID that maps to the IP address for each WINS server that appears in the database as an owner for records currently stored there.

    For practical purposes, WINS automatically assigns and increments an integer value for the owner ID and then maps that value to a corresponding server IP address. However, when you examine this information in the WINS console, only the owner IP address is actually displayed.

  2. When replication occurs with another WINS server, the version ID field for all records currently in the database is scanned for the highest version ID associated with each identified distinct owner.

A sample Owner/Version ID table for WINS-A when it is started might look like the following, if viewed using View Records in the WINS console:

Owner ID (not displayed) Owner Name    Highest ID

(0)

192.168.1.5   

WINS-A   

1F

(1)

192.168.2.5   

WINS-H   

125

(2)

192.168.3.5   

WINS-B   

31

(3)

192.168.4.5   

WINS-C   

100

(4)

192.168.5.5   

WINS-D   

200

The owner-version mappings are used by WINS to determine the state of the database at any point in time before or after replication. The following example provides more detailed information about how WINS manages replication.

Example: How pull replication works

The following graphic demonstrates how four WINS servers--WINS-A, WINS-B, WINS-C, and WINS-D--are all configured to be spokes (push/pull partners) of a central hub server, WINS-H.

Example: How pull replication works

Before replication with WINS-H, the owner-version mapping table at WINS-A contains a set of highest version IDs for all owners in its database. For the purpose of this example, assume these values are the same as those shown in the sample table provided in the previous section.

In reality, pull replication might be occurring dynamically between all four spokes at various times with WINS-H, so this table might not remain static for long. For a basic understanding of the details of an individual pull replication cycle, however, it is easier to focus on what might happen when just one of the spokes--for example, WINS-A--replicates its database with WINS-H.

In the graphic shown, the following changes in the replicated WINS network occur:

  1. The three other spokes (WINS-B, WINS-C and WINS-D) each replicate with WINS-H, based on the highest version ID.

    1. WINS-B has added or updated one new record since its last replication cycle, which WINS-H replicates and adds to its database.

    2. WINS-C has the same version ID and does not have any new records to be replicated at WINS-H.

    3. WINS-D has updated a total of 20 records since its last replication cycle, which WINS-H replicates and adds to its database.

  2. WINS-H sends a trigger to WINS-A initiating replication.

    The updated owner-version mapping table information is provided as part of the trigger.

  3. WINS-A responds by pulling entries from WINS-H.

    WINS-A determines which owner servers to pull from based on the difference between its locally held highest version ID for each owner and the corresponding updated highest version IDs provided by WINS-H. WINS-A specifies the range of records to be pulled and replicated by comparing versions.

Notes

  • In the case where another pull replication to the same partner is already queued, WINS sees the subsequent request as further down in the queue and discards it in favor of keeping the one with a higher placement in the service process queue.

  • In addition to modifying settings for pull replication properties, WINS also provides the option to enable the use of persistent connections with either a specified pull partner or all pull partners of a WINS server.

    For more information, see either Persistent connections or Enable the use of persistent connections with a partner server.