Sharing Concept Creating File ID on CreateRequest in DHT

Note: This is part three (of three) of creating a concept for file identifiers. Part one can be found here, part two here.

The third approach consists of sharing a generated, random UUID in the DHT.

Overview

• Generating IDs
• Exchanging IDs
• Sharing
  • Multiple Sharing Relations
• Unsharing
• Modifications on Owner Side
• Modifications on Sharer Side

Generating IDs

File IDs are randomly generated on the initial FilePushExchange of a particular file. Then, before sending the FilePushRequest to all other own clients, the ID is persisted in the DHT, using the as location key the user's username, as content key a configurable value (currently IDENTIFIER). To restrict modifications and access to clients of the same user, these values are domain protected.

The actual data persisted in the DHT, is a Map having as key the file path and as value the generated ID.

Exchanging IDs

Since clients may get out of sync due to high churn other connection-loss, they do not always persist FileIDs on a FilePushExchange. They check first, if any ID is already persisted in the DHT, and only if not, will inset a newly generated one.

Sharing

Once an End-User tries to share a particular file to another user, one of the first actions consists of fetching the file ID of the file to share from the DHT. Then, a SharedRequest is sent to all own clients, having as payload the relative file path and the sharer. All clients receiving such a request, are then required to insert the sharer to their object store. Once all clients have done so, a ShareExchange is started, actually sharing the file with a single client of the other user. Already in the initial request, the first chunk is sent to the other user's client. He will then fetch all chunks until completion using the received FileID.

Once the other user's client starts to persist chunks of shared files, he adds the FileId to the DHT on the namespace for the own user. Then he starts to write the chunks received until completion. Until the client has fetched all chunks, he will ignore any generated CreateEvents and ModifyEvents for the own clients. There will only on CreateEvent propagated once the client got all chunks of a particular file.

Multiple Sharing Relations

Since files can be shared with multiple users, there exists the possibility, that a file is shared with a client which already has the same file but shared from another user:

             Client 1
          /            \
         /              \
        /                \
    Client 2          Client 3
        \                /
         \              /
          \            /
             Client 4

Since files are identified by the same id over all sharers, Client 4 is able to detect that the same file is already shared with him, accepting the ShareRequest but not fetching the file.

Unsharing

Once a sharer should be removed from a particular file, the file's ID is fetched from the DHT again. Then an UnsharedRequest is sent to all own clients, causing them to remove the sharer from the particular file. After having completed this exchange, the actual UnshareRequest is sent to a single client of the sharer. He is then required to remove the inverse side of the sharing-relation from his object store (to prevent sending a delete event to the owning clients) and to delete the file from its storage, causing a DeleteEvent to be propagated to his own clients.

Modifications to the file on the owner side

• File content modifications made on the owner side of a sharing relation, are propagated to a single client of each sharer (READ and READ-WRITE access)
• Moving files to different directories are not propagated to the sharer
• File deletion is propagated to a single client of each sharer

Modifications to the file on the sharer side

• File content modifications made on the sharer side of a sharing relation, are propagated to a single client of the owning user. (only READ-WRITE access)
• Moving files to different directories are not propagated to the owner
• File deletion is propagated to a single client of the owner