File Exchanges

File Exchanges are responsible to propagate modifications of elements in the synchronised folder to the other peers, either the ones from the same user or, if shared, from the sharer too. In the following, these exchanges are shortly introduced.

File Offer Exchange

A FileOfferExchange is used to announce the actual modification to the other nodes. Each peer receiving the corresponding request (FileOfferRequest), has to verify on his local state of the synchronised folder (using the ObjectStore) that the obtained change is applicable. For the four different events, CreateEvent, ModifyEvent, MoveEvent and DeleteEvent, this means the following:

Create Event
Having received a CreateEvent, the node has to verify that either the element on the same path does not exist yet, or if it does, has the same content hash. If the hashes are different, then the receiving node renames his local version to a conflict file (in the form of <filename>_<nodeId>.<extension> and sends back a CONFLICT-Response. The renamed file is then synchronised again by starting a FileOfferExchange. If no conflict is detected, the node sends an ACCEPTED-Response back to the originating client.

Modify Event
Similar to the CreateEvent, a peer receiving a ModifyEvent has to check the last versions on his local state of the synchronised folder. If the version sent along with the FileOfferRequest differs and no common parent-version exists, a conflict file is created and a response with a CONFLICT flag is sent back. Otherwise, the peer returns an ACCEPTED-Response.

MoveEvent
A MoveEvent is handled by verifying that the target element does not exist or the version of the target is equal. If it differs, an exception occurs and the file is not moved. The state will then be reconciled using the BackgroundSyncer-process. If everything is as expected, the peer sends an ACCEPTED-Response back.

DeleteEvent
Finally, DeleteEvents are always accepted if the affected element exists. If it does not, the response is flagged with REQUEST_OBSOLETE preventing the sending node to transmit the following up FileDeleteRequest.

Besides sending ACCEPTED resp. CONFLICT responses, a node has a third option: He may indicate in his response that the following request is not required to be consistent. This type is used when a FileOfferRequest contains a version which the receiving peer already has.

File Push Exchange

This exchange sends the actual file data to other peers once the FileOfferingExchange has been positively completed. Data is sent in chunks of 1024^2 bytes. Each chunk is numbered, starting at 0, and its number is sent along the request. The receiving node then increases this counter on the corresponding response, specifying the chunk he does not have yet.As soon as all chunks have been obtained by the receiving peer, he generates a checksum to compare with the one of the FilePushRequest. If they differ, the node restarts the exchange by setting the required chunk counter back to zero.

File Delete and Move Exchange

Both exchanges work similarly: If the operation of the exchange, i.e. deleting resp. moving an element, pertains to a file, the operation is executed as expected: Either the element is deleted or moved. In case the element represents a directory, only exchanges for the top level of the affected folder are started. The operation is then invoked recursively on the receiving node, reducing the amount of network traffic.

File Demand Exchange

This exchange is responsible to fetch single elements from another peer. It works as the reverse from a FilePushExchange including the final verification of the checksum. Currently, it is only used by the BackgroundSyncer-process to fetch missing or outdated elements.