Delta Transfer of large binary files

The Delta Transfer feature is designed with the aim of improving performance by transferring only the deltas (modified portions) of large, uncompressed binary+F files to and from remote clients when they use:

  • p4 submit - supported on P4 Server and P4 CLI 2024.1 or later.

  • p4 sync - supported on P4 Server and P4 CLI 2024.2 or later.

  • p4 pull with the -u option for server-to-server replication on P4 Server 2025.1 or later.

Delta transfers tend to be more beneficial for connections on a slow network. On a very fast network, it might be quicker to transfer the entire file rather than incur the overhead of the calculations required to handle the changed content as a delta transfer.

You can configure delta transfer between clients and servers to have different behavior than delta transfer between servers during replication. For example, delta transfer might boost replication performance between a replica and its upstream server, but not be needed for submit and sync by clients of that replica. It also possible that delta transfer might boost performance for submit and sync by clients of that replica, but not be needed for replication between the replica and its upstream server.

Prerequisites

Proxy servers (P4P) do not cache delta transfers.

Configuration

You can customize the behavior of delta transfer to match your requirements. This is a summary of the relevant configurables in the P4 CLI Reference.

For submit and sync between a client and a server

net.delta.transfer.minsize is the minimum file size for delta transfers.

net.delta.transfer.threshold determines when to send the full file instead of delta chunks. If the percentage of differing chunks to total chunks is the greater than the threshold, the full file transfer will be initiated.

Replication delta transfer

Replication Delta Transfer is supported on all replica types: replica, forwarding-replica, build-server, edge-server, standby, and forwarding-standby.

For replication between servers Rules Limitations

net.delta.rpl.minsize is the minimum file size for delta transfers involving p4 pull -u.

If the downstream server sets either net.delta.rpl.minsize or net.delta.rpl.threshold to 0, delta transfer is turned off for that replica.

If the upstream server sets either net.delta.rpl.minsize or net.delta.rpl.threshold to 0, delta transfer is turned off for all downstream replicas.

The upstream server’s net.delta.rpl.minsize determines whether a file is too small for delta transfer.

The upstream server’s net.delta.rpl.threshold applies unless the downstream server’s net.delta.rpl.threshold is 0.

The lbr.replication configurable value must be readonly or cache.

The --batch and --trigger options of p4 pull disable the feature.

net.delta.rpl.threshold determines when to send the full file instead of delta chunks. If the percentage of differing chunks to total chunks is the greater than the threshold, the full file transfer will be initiated.
Proxy servers (P4P) do not cache delta transfers.

If the typemap is suitable, these types might use Delta Transfer

Delta transfers are limited to binary+F files, the "Uncompressed binary types". Some examples of that might be good candidates for delta transfer are .vmdk, .uasset, .iso, .tar, and .psd.

Some file types can be configured to work better with delta transfer. For example,

  • gzip files, if they are be created with the --rsyncable option.

  • .zip, .jar, .tiff, .pdf, and .wav files, if they are created without compression.

Examples of file formats that are not suitable for delta transfer

Not all binary+F files are suitable for delta transfer because the file might use a compression algorithm that causes the entire file to be completely rewritten when edited and saved. This means that unchanged content cannot be identified, and thus the entire file must be transfered. Examples include the .png, .gif, .jpg, .mpeg, .mp4, .docx and .xlsx file types.