FRS Does Not Compress for Replication as Directory Service Does (296971)

MORE INFORMATION

Allowing FRS to compress content--for example, HTML content, flat copies of programs, operating systems and languages, and network installations of programs--helps administrators to replicate across domain controllers. There is also a fault tolerance advantage, which is "content" in the sense that administrators can define shortcuts to create fault-tolerant application servers.

The compression functionality fits in the following four phases of the replication cycle:

• Exchanging information during member join time.
• Generating a staging file for a local change.
• Installing a remote change order.
• Sending a staging file to an outbound partner.

During the join time, members of a replica set that are connected go through a sequence of handshake actions before they send and receive data to or from the partner computer. The compression-related information is exchanged during this time.

At the join time, send the list of known compression formats to all inbound partners. The list is a list of Globally Unique Identifiers (GUIDs) that contains one GUID for each supported format. If an outbound partner sends a list of compression formats, and then saves it along with the other join time information for that connection, this list is used to determine what format to send the staging file in.

Do the following for a change that is generated locally:

1. Decide whether the file needs compression.
2. Save format information in the change order. The change order is stored in the staging file.
3. Compress the file to the appropriate format.

Do the following when you install a file that was created or updated on a remote computer:

1. Check to see whether the staging file is compressed. Always check the compression format bit from the change order structure that is part of the header for the staging file. The header is not compressed. The compression bit on the change order that is sent by the remote computer may not correspond to the compression bit on the change order in the staging file.
2. Find the compression format from the change order in the staging file.
3. Uncompress and install the file.

Do one of the following if an outbound partner requests a staging file for a change order:

• If the staging file is uncompressed, send it as it is.
• If the staging file is compressed, identify the compression format and use the list that was sent by this outbound partner during join time to determine whether this partner will accept the staging file in this format. If the partner cannot read the compression format, uncompress the file before you send the file. Update the compression bit in the change order that is part of the staging file to reflect the uncompressed format of the staging file.

Note that the decision about the format for sending the staging file is always made on the upstream member. This allows the upstream member to select the format that is most nearly applicable for all its outbound partners (future).

Also note that the staging file is uncompressed only once. Both the uncompressed and the compressed versions of the staging file are retained in the staging directory until all outbound partners have processed the related change order. This allows a mix of up-level and down-level partners to coexist and still allow the up-level partners to benefit from compression.

After the staging file passes through a down-level server, the file remains uncompressed for the rest of its journey.