Sharing Exchanges

Similar to FileExchanges, SharingExchanges propagate modifications on the sharing property of a particular element. Each change is first announced to the peers of the same node before notifying the sharer to ensure a common knowledge, allowing the sharer's peers to request files or push changes to any of the others.

To decouple the synchronised folders between the owner of an element and a sharer, each element has an attached file identifier. More about these ids can be found in the section about File Identifiers

Shared and Unshared Exchange

Before sharing the actual file, a SharedExchange is invoked with the nodes of the same user. A receiving peer then has to update the affected element in his ObjectStore, i.e. adding new access rights for the sharer.
Similar, the UnsharedExchange notifies the own peers of the access revocation of the user.

Share and Unshare Exchange

The actual file sharing is then started after the SharedExchange has been completed. One node of the sharer is notified about the new element and the access rights he obtains. Along this information, the first chunk of the element is also sent. Then the procedure continues as in a FilePushExchange, the receiving nodes increases the chunk counter until all have been received and then validates the checksum.
Once the file transfer has been completed, the sharer's node informs all corresponding peers of his user by invoking a FileOfferExchange.

To remove the access on the sharer's nodes, an UnshareExchange is started. Each node receiving the corresponding UnshareRequest has to remove the file from its local state. Again, only one peer obtains this information, propagation is ensured by the resulting FileDeleteExchange, once the element is removed.

A malicious peer, i.e. one which does not remove the file and the access rights on his side, is not able to push changes to nodes of the owner of the element. Each such incoming request is answered by an Access_Denied-response.