When a file is updated, PeerSync and the PSListener perform a series of steps to analyze the file and determine the exact blocks/segments that need to be transferred:
- When PeerSync detects that an update has been made, a rolling checksum is performed on the source and destination file. Typically, the PSListener is responsible for orchestrating the block requests and rebuilding the file on the destination.
- Based on the rolling checksum calculation, the PSListener requests only the specific missing blocks/segments of the file from PeerSync. It constructs the file in a temporary state using the local copy of the file and new blocks/segments that it receives from PeerSync. The temporary file will have either a *.pstmp or *.brtmp extension.
- Once the file is completely built, the original file is deleted and the temporary file is renamed. This two-step process ensures that the original target file is never left in an incomplete or corrupt state should something go wrong during the file building process. This method is used so that we do not interfere/manipulate the original target file. Only when the temporary file has been successfully built will the target file get deleted. You will need to ensure there is adequate space on the system for the creation of such temporary files.
- Can I use DFS Namespaces when specifying folder paths in PeerSync?
- Configure PeerSync Listener's advanced settings
- Configure the PeerSync Listener installer to run unattended
- Does PeerSync Listener have to be installed on both servers when using the ByteReplicator?
- How does the ByteReplicator work?
- Set up synchronization/replication over TCP
- What is the disk space requirement for PeerSync?
- Why does ByteReplicator use .BRTMP temporary files?