DidaWiki

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
==== F.A.Q. e note sul progetto conclusivo LPRb 07-08 ====

  * Giugno 2008 - //FSCK// Nel testo del progetto si parla di //controllare che esistano le k copie richieste// per ognuno dei file. In realtà va controllato che le copie esistano e siano consistenti. Qualora le copie esistano, ma non siano uguali, occorre provvedere alle opportune azioni correttive. 

  * 21 febbraio 2007 - //Nomi delle classi interfaccia// Nel testo del progetto si fa riferimento alle classi di interfaccia RemoteFileInputStreamIterface e RemoteFileOutputStreamInterface ma le interfacce riportate nel testo del progetto si chiamano in realtà RemoteInputStreamInterface e RemoteOutputStreamInterface. Il nome giusto è il primo, quindi usate in realtà RemoteFileInputStreamInterface e RemoteFileOutputStreamInterface. 


  * 14 dicembre 2007 - //Costruttori// Nelle interfacce per i file remoti in input e in output sono riportati anche i costruttori. Questi logicamente non fanno parte dell'interfaccia. Vanno semplicemente implementati con quella signature nella classe che implementerà l'interfaccia. Le interfacce saranno modificate nella versione "finale" del progetto. 

  * 14 dicembre 2007 - //Letture con risultati diversi per lo stesso blocco da server disco diversi// In caso di richiesta di lettura per un file, se i //k// server disco restituiscono versioni diverse dello stesso blocco, e se ''a maggioranza'' si può riconoscere una versione buona del blocco, è il server FileSystem che provvede a rendere omogeneo il blocco fra tutti i server disco coinvolti (secondo una procedura a vostro carico) e il blocco restituito al cliente è quello ''di maggioranza'' //senza// generare eccezioni. Va generata un'eccezione invece, nel caso in cui i //k// server disco diano //k// copie tutte diverse del blocco.

  * 12 dicembre 2007 - //Precisazione su architettura//  Nella realizzazione del progetto assumiamo che l'insieme dei processi che fungono da "FileServer" sia fisso e che il numero dei processi "fileServer" sia noto in fase di lancio dei processi stessi. Il numero dei processi "disco" non è noto a priori, invece, ma deve essere costantemente monitorato utilizzando meccanismi appropriati. La caduta di un server "disco" (terminazione del processo con un ^C, distacco dell'host su cui gira dalla rete, shutdown dell'host, reboot con Windows, etc.) deve essere trattata opportunamente, quando il sistema se ne accorga. Andrebbe anche trattato il caso del server "disco" che ricompare sulla rete (riavvio del server con tutti i file nella /tmp/sottodir).

  * 12 dicembre 2007 - // Scelte progettuali // Il testo del progetto lascia un largo margine di autonomia nella progettazione ed implementazione del File system sicuro. Qualunque scelta, anche semplificativa, adottata è valida purchè opportunamente motivata nella relazione. Ad esempio, se si scegliesse si non considerare la possibilità di "scomparsa" di un nodo di tipo "disco", il progetto è comunque valido se nella relazione tale scelta è discussa in modo adeguato (basta una frase che dica quale sia la scelta e perchè sia stata fatta). Ovviamente, la valutazione del progetto tiene conto anche del grado di semplificazione o complicazione introdotto dalle scelte dello studente. 

  * 10 dicembre 2007 - è stata creata la pagina, niente da segnalare al momento.