Daniele Giannetti
This code implements a distributed file repository, which has the following architecture:

 Client 1 <---|                               |---> File Server 1
              |                               |
              |                               |
 Client 2 <----------------> DFR <----------------> File Server 2
              |                               |
              |                               |
 Client 3 <---|                               |---> File Server 3
              |                               |
              |                               |
              .                               .
              .                               .

The DFR is the multithreaded process which implements the abstraction of distributed file repository, Clients request files to the DFR, those files are located on the File Servers. The base funcion of the DFR is to administer File Servers load and tell the Clients where to find a specific file they are looking for.


In the following we will refer to:


The base makefile in the DFR root directory can be directly used to build the code, as follows:


the clean make rule has been also defined to remove all non-source files from the project folder generated through a make command, as follows:

make clean

Makefiles have been defined for each singular component of the project, we have:

./src_DFR/Makefile ./src_FS/Makefile ./src_CL/Makefile ./src_common/Makefile

Which can be used to build the individual sections of the project using make or make clean as described above. An exception to this procedure is the ./src_common/Makefile which can be used to build only object files, and not executables, as follows:

[in folder ./src_common] make command.o make utility.o

Makefiles can be modified depending on the needs, they have been written for testing purpose, in particular note that some macros may be defined and passed to the compiler to obtain different behaviours:


Compiling the project using the global Makefile (simple make command) will produce 3 executable files in the ./bin directory from the code root. Those files are:

The usage of those files is the following:

 CL [DFR_IP_address_or_domain_name_for_CLs] [DFR_port_for_CLs] \
         [file_to_transfer] [new_filename] [mode] [delay]

 FS [DFR_IP_address_or_domain_name_for_FSs] \
         [DFR_port_for_FSs] [port_for_CLs] \
         [file1] [max_clients_for_file1] \
         [file2] [max_clients_for_file2] \
         [file3] [max_clients_for_file3] \

 DFR [IP_address_for_FSs] [IP_address_for_CSs] \
         [port_for_FSs] [port_for_CLs]


The code root folder contains a subfolder ./test/ In this folder we do have:

Created and continously rewritten files transferred from the FSs to the CLs are stored in folder ./test/test1_clients/, which can be then removed by the reset.sh script as described earlier.

Created files transferred from the FS to the CLs are stored in folder ./test/test2_clients/, which can be then removed by the reset.sh script as described earlier.

Generated on Sat Jun 13 21:06:30 2009 for DistributedFileRepository by  doxygen 1.5.8