finita relazione
This commit is contained in:
@ -85,7 +85,7 @@
|
|||||||
|
|
||||||
\section{Introduzione}
|
\section{Introduzione}
|
||||||
Il progetto realizzato consiste in un file storage gestito da un server multithreaded e un client che possono comunicarsi attraverso le funzioni implementate dall'API.
|
Il progetto realizzato consiste in un file storage gestito da un server multithreaded e un client che possono comunicarsi attraverso le funzioni implementate dall'API.
|
||||||
Il codice è presente sulla repository privata al link: \href{http://google.com}{TODO}.\\
|
Il codice è presente sulla repository privata al link: \href{http://tautocrono.it}{tautocrono.it}.\\
|
||||||
Si può accedere usando le credenziali:
|
Si può accedere usando le credenziali:
|
||||||
|
|
||||||
\begin{center}
|
\begin{center}
|
||||||
@ -101,15 +101,21 @@ Ci sono anche i target clean e cleanall che rimuovono gli eseguibili creati con
|
|||||||
|
|
||||||
Sono inclusi anche dei file per testare le funzionalità del client e del server nella cartella \textit{testFiles}.
|
Sono inclusi anche dei file per testare le funzionalità del client e del server nella cartella \textit{testFiles}.
|
||||||
|
|
||||||
|
Gli oggetti vengono creati nella directory \textit{obj/}, mentre gli eseguibili vengono creati nella directory \textit{build/}.
|
||||||
|
La directory \textit{src/} contiene il codice che fa parte del main del server e del client; il resto del codice è contenuto nella directory \textit{lib/}.
|
||||||
|
|
||||||
|
È stata implementata sia la politica di rimpiazzamento FIFO che la politica LRU.
|
||||||
|
|
||||||
|
|
||||||
%% ------------------------- %%
|
%% ------------------------- %%
|
||||||
|
|
||||||
\section{Server}
|
\section{Server}
|
||||||
Il server prende come unico argomento il path al file di configurazione. Un esempio di file di configurazione è \texttt{config.ini} presente nella root del progetto. La struttura del file è analoga a quella di un file \href{https://en.wikipedia.org/wiki/INI_file}{INI}, quindi l'ordine degli argomenti è irrilevante.
|
Il server prende come unico argomento il path al file di configurazione. Un esempio di file di configurazione è \texttt{config.ini} presente nella root del progetto. La struttura del file è analoga a quella di un file \href{https://en.wikipedia.org/wiki/INI_file}{INI}, quindi l'ordine degli argomenti dentro a sezione è irrilevante.
|
||||||
Il file di configurazione viene letto da una libreria di "\textit{terza parte}" ottenuta da \href{https://github.com/rxi/ini}{rxi/ini}.
|
Il file di configurazione viene letto da una libreria di "\textit{terza parte}" ottenuta da \href{https://github.com/rxi/ini}{rxi/ini}. Si sarebbe potuto usare la libreria \href{https://gitlab.gnome.org/GNOME/glib}{Glib} tuttavia si è riscontrata una memory leak con valgrind.
|
||||||
|
|
||||||
La libreria threadpool e la libreria conn sono state tratte dalla soluzione dell'esercitazione 11 pubblicata sulla pagina del corso.
|
La libreria threadpool e la libreria conn sono state tratte dalla soluzione dell'esercitazione 11 pubblicata sulla pagina del corso.
|
||||||
Si è preferito l'utilizzo di \texttt{strsep} invece di \texttt{strtok} o \texttt{strtok\_r} sia nel programma server che client.
|
Si è preferito l'utilizzo di \texttt{strsep} invece di \texttt{strtok} o \texttt{strtok\_r} sia nel programma server che client.
|
||||||
Il codice è stato adattato leggermente da quello presente nella libreria C GNU (\href{https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strsep.c;h=b534a1ec17fd2e91087af04abe1c3f1ac3e74ce0;hb=HEAD}{strsep}) in modo da utilizzare la funzione omonima su piattaforme BSD.
|
Il codice è stato adattato leggermente da quello presente nella libreria C GNU (\href{https://sourceware.org/git/?p=glibc.git;a=blob;f=string/strsep.c;h=b534a1ec17fd2e91087af04abe1c3f1ac3e74ce0;hb=HEAD}{strsep}) in modo da utilizzare la funzione omonima su piattaforme BSD e MacOS.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Main}
|
\subsection{Main}
|
||||||
@ -134,8 +140,10 @@ Se il segnale ricevuto è del tipo \texttt{SIGHUP} invece si attende che ogni wo
|
|||||||
\section{Storage}
|
\section{Storage}
|
||||||
|
|
||||||
Il server gestisce la memorizzazione dei file tramite la libreria \textit{fileQueue}.
|
Il server gestisce la memorizzazione dei file tramite la libreria \textit{fileQueue}.
|
||||||
|
Nel header file \textit{fileQueue.h} la costante \texttt{ALGORITHM} imposta la politica di rimpiazzamento. Le funzioni che differiscono in comportamento sono: \texttt{dequeueN}, \texttt{lockFileInQueue}, \texttt{unlockFileInQueue}, \texttt{openFileInQueue}, \texttt{find}, \texttt{request}, \texttt{searchFile}. Infatti l'elemento che richiedono come input viene accodato alla fine della struttura nella politica LRU. Le altre funzioni invece non modificano l'ordine degli elementi.
|
||||||
|
|
||||||
La struttura principale è una linked list chiamata \texttt{nodeT} che contiene i dati del file associato e un puntatore al prossimo elemento.
|
La struttura principale è una linked list chiamata \texttt{nodeT} che contiene i dati del file associato e un puntatore al prossimo elemento.
|
||||||
Dato che l'operazione di scrittura di un file in memoria non è atomica, si è deciso di usare due misure dell'occupazione della memoria da un file: \texttt{size} e \texttt{valid}.
|
Dato che l'operazione di scrittura di un file in memoria non è atomica, si è deciso di usare due misure dell'occupazione della memoria di un file: \texttt{size} e \texttt{valid}.
|
||||||
L'unico momento in cui potrebbero essere differenti è quando il client ha richiesto la scrittura di dati, comunicando la dimensione, quindi il server "alloca" tale dimensione come \texttt{size}, lasciando invariato la dimensione \texttt{valid}. Dopo che il client ha inviato i dati da inserire nel file, le dimensioni dovrebbero di nuovo combaciare.
|
L'unico momento in cui potrebbero essere differenti è quando il client ha richiesto la scrittura di dati, comunicando la dimensione, quindi il server "alloca" tale dimensione come \texttt{size}, lasciando invariato la dimensione \texttt{valid}. Dopo che il client ha inviato i dati da inserire nel file, le dimensioni dovrebbero di nuovo combaciare.
|
||||||
Una singola operazione di scrittura può richiedere più di un file rimosso per aver abbastanza memoria libera; questa operazione viene attuata atomicamente e viene considerata come un'unica operazione di rimpiazzamento.
|
Una singola operazione di scrittura può richiedere più di un file rimosso per aver abbastanza memoria libera; questa operazione viene attuata atomicamente e viene considerata come un'unica operazione di rimpiazzamento.
|
||||||
|
|
||||||
@ -149,7 +157,7 @@ Le scritture vengono sincronizzate tramite lock.
|
|||||||
Sono state scritte due funzioni che permettono la scrittura: \texttt{taglia\_write}, \texttt{taglia\_log}.
|
Sono state scritte due funzioni che permettono la scrittura: \texttt{taglia\_write}, \texttt{taglia\_log}.
|
||||||
\texttt{taglia\_log} scrive anche un timestamp prima del messaggio di log.
|
\texttt{taglia\_log} scrive anche un timestamp prima del messaggio di log.
|
||||||
All'inizio dell'esecuzione del server vengono stampate alcune informazioni lette dal file di configurazione, come ad esempio la dimensione del threadpool o la dimensione massima della struttura di cache del server.
|
All'inizio dell'esecuzione del server vengono stampate alcune informazioni lette dal file di configurazione, come ad esempio la dimensione del threadpool o la dimensione massima della struttura di cache del server.
|
||||||
Al termine vengono invece scritti alcuni dati di sunto delle operazioni, come ad esempio il numero massimo di file memorizzati o la dimensione massima raggiunta.
|
Al termine vengono invece scritti alcuni dati di sunto delle operazioni, ad esempio il numero massimo di file memorizzati o la dimensione massima raggiunta.
|
||||||
|
|
||||||
|
|
||||||
%% ------------------------- %%
|
%% ------------------------- %%
|
||||||
@ -158,6 +166,11 @@ Al termine vengono invece scritti alcuni dati di sunto delle operazioni, come ad
|
|||||||
|
|
||||||
Oltre alle funzioni di API richieste dalla specifica è stata implementata la funzione \texttt{setDirectory}, perchè si è interpretata come se le opzioni \texttt{-d} e \texttt{-D} dovessero poter essere associate a più di un comando. Tuttavia questa funzionalità non è presente nel client in modo diretto dato che vengono inserite \texttt{-d}/\texttt{-D /dev/null} fra due opzioni \texttt{-w}/\texttt{-W} o \texttt{-r}/\texttt{-R} successive.
|
Oltre alle funzioni di API richieste dalla specifica è stata implementata la funzione \texttt{setDirectory}, perchè si è interpretata come se le opzioni \texttt{-d} e \texttt{-D} dovessero poter essere associate a più di un comando. Tuttavia questa funzionalità non è presente nel client in modo diretto dato che vengono inserite \texttt{-d}/\texttt{-D /dev/null} fra due opzioni \texttt{-w}/\texttt{-W} o \texttt{-r}/\texttt{-R} successive.
|
||||||
L'opzione \texttt{-d /dev/null} o \texttt{-D /dev/null} è stata ottimizzata leggermente in modo da non fare chiamate di sistema.
|
L'opzione \texttt{-d /dev/null} o \texttt{-D /dev/null} è stata ottimizzata leggermente in modo da non fare chiamate di sistema.
|
||||||
|
\\
|
||||||
|
|
||||||
|
Il client esegue prima l'opzione \texttt{-f}, in seguito l'opzione \texttt{-t}, poi in ordine tutti gli altri argomenti.
|
||||||
|
In caso di errore durante la scrittura su un file dopo la creazione, il client richiede la rimozione del file.
|
||||||
|
\\
|
||||||
|
|
||||||
Per la comunicazione con il server si è optato per un protocollo ispirato a quello html o ftp, costituito da due cifre, la prima denota il risultato (positive completion/transient negative completion/permanent negative completion), la seconda invece è una specifica della prima. Non tutte le combinazioni sono state usate.
|
Per la comunicazione con il server si è optato per un protocollo ispirato a quello html o ftp, costituito da due cifre, la prima denota il risultato (positive completion/transient negative completion/permanent negative completion), la seconda invece è una specifica della prima. Non tutte le combinazioni sono state usate.
|
||||||
|
|
||||||
@ -205,7 +218,6 @@ Il server risponde prima con due caratteri che simboleggiano is response number,
|
|||||||
Il server per inviare i file richiesti o espulsi, prima invia il numero di file, poi per ogni file la dimensione come \texttt{int64\_t} e poi successivamente il file.
|
Il server per inviare i file richiesti o espulsi, prima invia il numero di file, poi per ogni file la dimensione come \texttt{int64\_t} e poi successivamente il file.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
%% ------------------------- %%
|
%% ------------------------- %%
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -11,7 +11,7 @@
|
|||||||
se = 0 -> FIFO
|
se = 0 -> FIFO
|
||||||
se = 1 -> LRU
|
se = 1 -> LRU
|
||||||
*/
|
*/
|
||||||
#define ALGORITHM 1
|
#define ALGORITHM 0
|
||||||
|
|
||||||
/* struttura dati per gestire i file in memoria principale */
|
/* struttura dati per gestire i file in memoria principale */
|
||||||
typedef struct {
|
typedef struct {
|
||||||
|
|||||||
Reference in New Issue
Block a user