3.3.4.4.6 COMM_COMMAND Is CMD_REMOTE_CO

The server MUST be the downstream partner to receive this call. The upstream partner has sent a remote change order to the downstream partner.

The downstream partner MUST determine if the remote change order is for a folder or file.

If CO_FLAG_LOCATION_CMD is set inside CO_IN.Flags:

  • If CO_IN.LocationCmd.DirOrFile is 1, the remote change order is for a folder.

  • If CO_IN.LocationCmd.DirOrFile is 0, the remote change order is for a file.

If CO_FLAG_LOCATION_CMD is NOT set inside CO_IN.Flags:

  • If FILE_ATTRIBUTE_DIRECTORY(0x10) flag is set in CO_IN.FileAttributes, the remote change order is for a folder.

  • If FILE_ATTRIBUTE_DIRECTORY(0x10) flag is NOT set in CO_IN.FileAttributes, the remote change order is for a file.

If CO_LOCATION_DELETE or CO_LOCATION_MOVEOUT flag is set in CO_IN.LocationCmd, the change order specifies a deletion for either an endpoint file or folder.

When the change order is not for a deletion, if CO_FLAG_CONTENT_CMD is set in CO_IN.Flags, CO_IN.ContentCmd specifies the nature of the change:

  • REASON_RENAME_NEW_NAME specifies a renaming.

  • All other reasons are treated as a copy command.

If the change order is not a deletion or a renaming, the change order is treated as a copying.

If CO_FLAG_OUT_OF_ORDER flag is set in the change order, the change order MUST NOT be dampened (a dampened change order does not need to be processed because it does not contain new information about a file or folder).

If CO_FLAG_OUT_OF_ORDER flag is not set in the change order, find the corresponding VSN for CO_IN.OriginatorGuid inside the local replica member version vector. If the VSN is larger or equal to CO_IN.FrsVsn, the change order MUST be dampened.

If a change order is dampened, the downstream partner MUST send out CMD_REMOTE_CO_DONE (see section 3.3.4.4.6.2).

If the change order is not dampened, the downstream partner MUST verify if there are any naming (multiple replica members create files or folders with the same name under the replica tree) or update conflicts (multiple replica members update the same files or folders). If there are conflicts, the downstream partner MUST resolve the conflicts to make data consistent among the replica members.

If identically named files are created or modified on two or more replica members, the downstream partner MUST use a "last writer wins" rule; this means that the most recently created or modified version of a file becomes the version that is replicated to the other replica members. All change orders have event times in Coordinated Universal Time (UTC).

These event times are used for comparison to the IDTable:

  • Event Time delta > 30 minutes: Last writer wins.

  • Event Time delta <= 30 minutes: Highest version wins (that is, most prolific writer wins).

  • If both the event times and versions match, the file with a larger size wins.

  • If the file size also matches, the change order with a larger Originator GUID wins.

  • If the Originator GUID also matches, the local file loses.

If identically named folders are created on two or more replica members, the downstream partner identifies the conflict during replication and renames the folder that was most recently created (using a morphed name). Both folders MUST be replicated to all servers in the replica set. The morphed names MUST have a suffix of the form _NTFRS_xxxxxxxx added to the end of the folder name, where "xxxxxxxx" represents eight random hexadecimal digits. Administrators MAY be notified about morphed names.

The downstream partner MAY <84> suppress identical files and folders that it receives more than once.

When a conflict is detected, if the change order inside P_IN loses, the change order is abandoned and the server MUST send out CMD_REMOTE_CO_DONE packet (see section 3.3.4.4.6.2).

If the change order is the winner or there is no conflict, the downstream partner MUST put this change order in the inbound connection inbound log. The downstream partner MUST check the CO_FLAG_VVJOIN_TO_ORIG flag inside P_IN.COMM_REMOTE_CO.Flags:

  • If CO_FLAG_VVJOIN_TO_ORIG flag is set, the downstream partner MUST perform initial sync.

  • Otherwise, the downstream partner MUST perform normal sync.

The downstream partner MUST determine if a staging file is needed for CO_IN.

If CO_FLAG_LOCATION_CMD is set inside CO_IN.Flags:

  • If CO_IN.LocationCmd is one of the following, a staging file MUST be needed:

    • CO_LOCATION_CREATE

    • CO_LOCATION_MOVEIN

    • CO_LOCATION_MOVEIN2

  • If CO_IN.LocationCmd is one of the following, no staging file is needed:

    • CO_LOCATION_DELETE

    • CO_LOCATION_MOVEOUT

  • If CO_IN.LocationCmd is either CO_LOCATION_MOVERS or CO_LOCATION_MOVEDIR, the downstream partner MUST check CO_IN.ContentCmd to determine if a staging file is needed.

If the downstream partner cannot determine if a staging file is needed from CO_IN.LocationCmd, the downstream partner MUST check if the CO_FLAG_CONTENT_CMD flag is set in CO_IN.Flags:

  • If CO_FLAG_CONTENT_CMD is not set in CO_IN.Flags, no staging file is needed.

  • If CO_FLAG_CONTENT_CMD is set in CO_IN.Flags, the downstream partner MUST determine if one or more values are set in CO_IN.ContentCmd:

    • If one or more values are set in CO_IN.ContentCmd, a staging file is needed.

    • If no value is set in CO_IN.ContentCmd, a staging file is not needed.

If a staging file is not needed, the downstream partner MUST NOT request a staging file from the upstream partner. The downstream partner MUST send out the CMD_REMOTE_CO_DONE packet (see section 3.3.4.4.6.2).

If a staging file is needed, the downstream partner MUST request a staging file from the upstream partner through CMD_SEND_STAGE packets (see section 3.3.4.4.6.1). For each CMD_SEND_STAGE packet, the upstream partner MUST send a fixed size of staging file data to the downstream partner through the CMD_RECEIVING packet. The last CMD_RECEIVING packet might have less than the fixed size of staging file data. (The downstream partner does not try to pad the last packet to make all CMD_RECEIVING packets the same size.)<85>

After all parts of the staging file are downloaded (or no staging file is required), the downstream partner MUST send the upstream partner a CMD_REMOTE_CO_DONE packet to acknowledge that the change order has been successfully processed on the downstream partner (see section 3.3.4.4.6.2). The downstream partner MUST update the local replica member version vector accordingly, except if the CO_FLAG_SKIP_VV_UPDATE flag is set in CO_IN; then this downstream partner MUST forward this change order to all other downstream partners by CMD_REMOTE_CO packet.

Both CMD_REMOTE_CO_DONE and CMD_SEND_STAGE MUST include a change order in their packets. Following are common details for those change orders (these details are not listed in sections 3.3.4.4.6.1 and 3.3.4.4.6.2).

SequenceNumber: MUST be a number that is larger than any change order sequence number in the current member outbound log. The sequence number MUST start at one and MUST be incremented with each change order that goes into the outbound log. The sequence number MUST be unique per replica set per machine.

FileAttribute: MUST be CO_IN.FileAttribute.

FileVersionNumber: MUST be CO_IN.FileVersionNumber.

PartnerAckSeqNumber: MUST be CO_IN.PartnerAckSeqNumber.

FileSize: MUST be CO_IN.FileSize.

FrsVsn: MUST be CO_IN.FrsVsn.

FileUSN: A 64-bit, unsigned integer that MUST indicate the internal implementation-specific data on the current replica member. This value is only meaningful on the current replica member and has no meaning on any other replica member. Once the change order is sent to another replica member, the receiving partner MUST ignore this field.

JrnlUSN: A 64-bit, unsigned integer that MUST indicate the internal implementation-specific data on the current replica member. This value is only meaningful on the current replica member and has no meaning on any other replica member. Once the change order is sent to another replica member, the receiving partner MUST ignore this field.

JrnlFirstUSN: A 64-bit, unsigned integer that MUST indicate the internal implementation-specific data on the current replica member. This value is only meaningful on the current replica member and has no meaning on any other replica member. Once the change order is sent to another replica member, the receiving partner MUST ignore this field.

OriginalReplicaNumber: A 32-bit, unsigned integer that MUST indicate the internal implementation-specific data on the current replica member. This value is only meaningful on the current replica member and has no meaning on any other replica member. Once the change order is sent to another replica member, the receiving partner MUST ignore this field.

NewReplicaNumber: A 32-bit, unsigned integer that MUST indicate the internal implementation-specific data on the current replica member. This value is only meaningful on the current replica member and has no meaning on any other replica member. Once the change order is sent to another replica member, the receiving partner MUST ignore this field.

ChangeOrderGuid: MUST be CO_IN.ChangeOrderGuid.

OriginatorGuid: MUST be CO_IN.OriginatorGuid.

FileGuid: MUST be CO_IN.FileGuid.

OldParentGuid: MUST be the local replica tree root GUID if the parent is the replica tree root; otherwise, set it to CO_IN.OldParentGuid.

NewParentGuid: MUST be the local replica tree root GUID if the parent is the replica tree root; otherwise, set it to CO_IN.NewParentGuid.

CxtionGuid: MUST be CO_IN.CxtionGuid.

AckVersion: MUST be CO_IN.AckVersion.

Flags: Specified in sections 3.3.4.4.6.1 and 3.3.4.4.6.2.

IFlags: Specified in sections 3.3.4.4.6.1 and 3.3.4.4.6.2.

State: Specified in sections 3.3.4.4.6.1 and 3.3.4.4.6.2.

ContentCmd: Specified in sections 3.3.4.4.6.1 and 3.3.4.4.6.2.

FileOffset: Specified in sections 3.3.4.4.6.1 and 3.3.4.4.6.2.