1500. Design a File Sharing System π
Description
We will use a file-sharing system to share a very large file which consists of m small chunks with IDs from 1 to m.
When users join the system, the system should assign a unique ID to them. The unique ID should be used once for each user, but when a user leaves the system, the ID can be reused again.
Users can request a certain chunk of the file, the system should return a list of IDs of all the users who own this chunk. If the user receives a non-empty list of IDs, they receive the requested chunk successfully.
Implement the FileSharing class:
FileSharing(int m)Initializes the object with a file ofmchunks.int join(int[] ownedChunks): A new user joined the system owning some chunks of the file, the system should assign an id to the user which is the smallest positive integer not taken by any other user. Return the assigned id.void leave(int userID): The user withuserIDwill leave the system, you cannot take file chunks from them anymore.int[] request(int userID, int chunkID): The useruserIDrequested the file chunk withchunkID. Return a list of the IDs of all users that own this chunk sorted in ascending order.
Example:
Input: ["FileSharing","join","join","join","request","request","leave","request","leave","join"] [[4],[[1,2]],[[2,3]],[[4]],[1,3],[2,2],[1],[2,1],[2],[[]]] Output: [null,1,2,3,[2],[1,2],null,[],null,1] Explanation: FileSharing fileSharing = new FileSharing(4); // We use the system to share a file of 4 chunks. fileSharing.join([1, 2]); // A user who has chunks [1,2] joined the system, assign id = 1 to them and return 1. fileSharing.join([2, 3]); // A user who has chunks [2,3] joined the system, assign id = 2 to them and return 2. fileSharing.join([4]); // A user who has chunk [4] joined the system, assign id = 3 to them and return 3. fileSharing.request(1, 3); // The user with id = 1 requested the third file chunk, as only the user with id = 2 has the file, return [2] . Notice that user 1 now has chunks [1,2,3]. fileSharing.request(2, 2); // The user with id = 2 requested the second file chunk, users with ids [1,2] have this chunk, thus we return [1,2]. fileSharing.leave(1); // The user with id = 1 left the system, all the file chunks with them are no longer available for other users. fileSharing.request(2, 1); // The user with id = 2 requested the first file chunk, no one in the system has this chunk, we return empty list []. fileSharing.leave(2); // The user with id = 2 left the system. fileSharing.join([]); // A user who doesn't have any chunks joined the system, assign id = 1 to them and return 1. Notice that ids 1 and 2 are free and we can reuse them.
Constraints:
1 <= m <= 1050 <= ownedChunks.length <= min(100, m)1 <= ownedChunks[i] <= m- Values of
ownedChunksare unique. 1 <= chunkID <= muserIDis guaranteed to be a user in the system if you assign the IDs correctly.- At most
104calls will be made tojoin,leaveandrequest. - Each call to
leavewill have a matching call forjoin.
Follow-up:
- What happens if the system identifies the user by their IP address instead of their unique ID and users disconnect and connect from the system with the same IP?
- If the users in the system join and leave the system frequently without requesting any chunks, will your solution still be efficient?
- If all users join the system one time, request all files, and then leave, will your solution still be efficient?
- If the system will be used to share
nfiles where theithfile consists ofm[i], what are the changes you have to make?
Solutions
Solution 1
Thinking
Each join must receive the smallest unused positive id, and a left id must become reusable at once; we also track which chunks each user holds and, on request, return every user who currently owns that chunk. Scanning from \(1\) on every join would cost linear time in the number of historical users, which is unattractive when there are up to \(10^4\) calls and \(m \le 10^5\).
While no id has been recycled, new ids increase monotonically; freed ids form a reusable pool. An incrementing counter issues fresh ids and a min-heap stores released ones, so the smallest free id is available in logarithmic time. A hash map stores user \(\to\) chunk set. A request scans currently online users, which is acceptable under the call limit; if the result is nonempty, the requester also receives that chunk.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 | |