Highlights
1 Project Objective
The objective of this assignment is to apply the knowledge of client-server communicationand Remote Method Invocation (RMI) to build a distributed file system, which we refer to as Remote and Distributed File Storage (or simply DFS). RMI involves the creation of stubs and skeletons at client and server sides, respectively which allow for transparent location, reading and writing of files maintained at networked computers. In RMI, the underlying details are generally hidden from users, whereby a calling object can invoke a method in a potentially remote node as if it is local.
2 DFS
The following subsections will provide an overview of DFS, followed by descriptions of its inherent functionalities, entities, architecture, communication betweenentities and the required RMI library and interfaces.
2.1 Overview
In this project, you will implement DFS, a distributed file system that stores a vast amount of data (files) which typically do not fit on a single machine. Briefly, the files are physically stored on a set of servers called Storage Servers. Users, referred to as Clients, can create, delete, read, write, and list files (among others), all via using Remote Method Invocation (RMI). As a requisite step, Clients need to identify Storage Servers that host the required files. They do so with the help of a mediator. Clients contact a Naming Server (in this project we allow only one centralized Naming Server) which maps every file name to a Storage Server. The Naming Server is thus a repository of metadata or data about data.
2.2 Functionalities
The operations (or functionalities) that are available to the Clients of DFS are:
1. CreateFile(path): create the file referred to by path1.
2. CreateDirectory(path) : create the directory referred to by path.
3. Read(path, o, n) : read n bytes of data from the file referred to by path starting at an offset o.
4. Write(path, o, data) : write n bytes of data to the file referred to by path starting at an offset o.
5. Size(path): return the size, in bytes, of the file referred to by path.
6. IsDirectory(path) : return true if path refers to a directory.
7. List(path): list the contents of the directory referred to by path.
8. Delete(path): delete the file or directory referred to by path.
9. GetStorage(path) : get the Storage Server (or more precisely, a representing stub) hosting the file referred to by path.
Entities, Architecture, and Communication
The main entities in DFS are: Clients, Naming Server, and Storage Servers. A Client is the end-user of DFS who wishes to perform operations on files. We assume that a Client knows the path of a file it wishes to manipulate. The Naming Server is a critical entity in DFS because it is the means by which Clients locate files stored at Storage Servers. It runs at a pre-dened address that is known by both, Clients and Storage Servers. A Storage Server
physically stores files in its local file system. The project assumes that a file cannot be partitioned across Storage Servers (i.e., no file striping is applied) and that a Storage Server can host multiple files.
DFS is based on a client-server architecture as shown in Figure 1. In this architecture, a client is service requester and a server is a service provider. Servers also behave as clients when requesting services provided by other servers. For example, the Naming Server behaves as a client when requesting the services of a Storage Server. In Figure 1, all forward arrows (arrows 2, 3, and 5) represent requests originating from clients to servers, and the corresponding backward arrows represent the services provided by the servers in response.
It is evident from the arrows in Figure 1 that distributed systems entail a lot of communication between its entities. DFS is no exception. We will now discuss the purpose of communication in DFS and the communicating entities.
2.3.1 Storage Servers - Naming Server Communication
Upon start-up, each Storage Server sends a list of paths (representing the files that it currently hosts) to the Naming Server, a process we denote as registration. The Naming Server then traverses this list and adds the paths to its directory tree where each leaf node is a (filename, Storage Server) tuple. During the traversal, the Naming Server remembers
paths of existing files and ultimately replies back to the Storage Server with a list of duplicate paths (see Section 5.3 for details on that). Figure 1 depicts this communication with arrows 1 and 2. After registration by all Storage Servers, the Naming Server is deemed to be capable of locating all files stored at each Storage Server.2.3.2 Client - Naming Server CommunicationArrows 3 and 4 in Figure 1 illustrate this communication. A Client contacts the Naming Server whenever it needs to perform an operation on a file. While some operations cannot be directly handled by the Naming Server, in which case it replies back withthe Storage Server that hosts the file, other operations can be directly handled by it.
Operations requiring the content of a file namely read, write and size, cannot be directly handled by the Naming Server. When a Client wishes to perform any of those operations, it first contacts the Naming Server to get the Storage Server (or more precisely a representing stub) that hosts the file. It does so using the getStorage operation and, subsequently, communicates with the respective Storage Server to handle the operation. In Figure 1, arrows 5 and 6 mark this communication.All the other operations, namely: createFile, createDirectory, isDirectory, list, and delete, can be handled by the Naming Server without involving the Storage Servers. This is because the Naming Server merely leverages its tree to handle such operations without requiring file contents. It also ensures the integrity of the Naming Server's directory tree. Clients cannot create/delete files/directories on the Storage Servers without the awareness of the Naming Server. Therefore, the Naming Server first updates its directory tree by adding/deleting a file/directory and then instructs the respective Storage Server to perform the physical creation/deletion.You have to create a design that supports the delete operation without actually implementing it. The implementation of the delete operation iabonus-question in this assignment.
2.3.3 Naming Server - Storage Servers Communication
This communication is illustrated in Figure 1 by arrows 1 and 2. Upon start-up, each Storage Server recursively lists its hosted files and sends the resultant list of paths to the Naming Server. As described earlier, we denote this process as registration. In response, the Naming Server replies with a list of duplicate files (if any) which a Storage Server deletes from its local file system. In addition, it also deletes any directories that are rendered empty, a process known as pruning.Besides their communication upon boot-strapping DFS, the Naming Server sends create and delete operations to Storage Servers on behalf of Clients after changes to its directory tree have been successfully committed.
2.3.4 Client- Storage Servers Communication Arrows 5 and 6 illustrate this communication that occurs when a Client wishes to perform a read, write, or size operation,after retrieving the respective Storage Server from the Naming Server (see Client - Naming Server Communication above).
This COMP6231 - IT Assignment has been solved by our IT Experts at My Uni Paper. Our Assignment Writing Experts are efficient to provide a fresh solution to this question. We are serving more than 10000+Students in Australia, UK & US by helping them to score HD in their academics. Our Experts are well trained to follow all marking rubrics & referencing style.
Be it a used or new solution, the quality of the work submitted by our assignment Experts remains unhampered. You may continue to expect the same or even better quality with the used and new assignment solution files respectively. There’s one thing to be noticed that you could choose one between the two and acquire an HD either way. You could choose a new assignment solution file to get yourself an exclusive, plagiarism (with free Turnitin file), expert quality assignment or order an old solution file that was considered worthy of the highest distinction.
© Copyright 2026 My Uni Papers – Student Hustle Made Hassle Free. All rights reserved.