Progetto di Reti di Calcolatori

Decisione di migrazione in sistemi distribuiti

Considerazioni:

Il progetto mi ha offerto la possibilita' di confrontarmi con una situazione reale, e di dover quindi acquisire dimestichezza con le macchine unix del laboratorio e con gli strumenti di comunicazione piu' comuni all' interno delle reti, cioe' le socket.

Le difficolta' non sono state poche nonostante il progetto non fosse particolarmente ambizioso.

La prima si e' presentata nell utilizzare le classi per implementare l'algoritmo.

Il compilatore generava una serie di warning che si traducevano poi in una impossibilita' di esecuzione.

A fronte di questi inconvenienti ho scelto di togliere le classi dal programma, per la verita' poco significative per il progetto, introdotte piu' che altro per realizzare un' astrazione dell'oggetto NODO di cui si e' parlato alle pagine precedenti;

Archiviata dunque rapidamente la compilazione, il problema successivo e' venuto dalla procedura che calcolava i processi sul nodo mediante la generazione di un figlio.

L'elaborato, saltuariamente ed in maniera casuale, non eseguiva la fork.

Questo problema si e' ripresentato piu' avanti, nelle procedure che generavano figli per realizzare un server concorrente.

L'inconveniente si e' risolto in maniera insperata, durante un tentativo di debuging, assegnando ad una variabile il valore di ritorno della fork. Da allora i figli vengono sempre generati.

Sinceramente non so spiegarne la ragione; immagino si tratti di un dettaglio legato al particolare compilatore (il gcc) anche se non posso affermarlo con certezza poiche' dalla documentazione in mio possesso e dal man di linea di solaris non sono riuscito a trovare riferimenti al caso specifico.

Gli ultimi problemi hanno riguardato le primitive di comunicazione read e write.

In particolare le write che non spedivano un numero di caratteri pari alla dimensione della stringa, venivano bufferizzate, e quetso causava la sospensione delle read concorrenti e conseguentemente di tutto il programma, visto che il sistema e' stato progettato in modo che ogni comunicazione rappresenti un punto di sincronismo.

Per risolvere questo inconveniente si e' ricorso alla funzione fflush, la quale accetta, in ingresso, un argomento di tipo FILE *stream e cio' ha richiesto un po' di tempo per trovare una funzione che trasformasse l'identificatore intero della socket nel formato richiesto. Tale funzione e' la fdopen.

Infine il programma si bloccava sulla ultima read prima della chiusura della socket.

Supponendo di chiamare R il processo contenente l'ultima read di una comunicazione e W quello omologo contenente l'ultima write, W dopo la write chiudeva la socket (dal suo lato) sia in lettura che scrittura, ed R (forse vittima di uno sfortunato scheduling) si trovava a leggere da una socket chiusa.

Questo problema e' stato superato utilizzando la shutdown per chiudere la socket in lettura, prima dell'ultima write.

Alla fine, l'algoritmo ha risposto agli obiettivi di progetto realizzando un load balancing conforme alle specifiche.

Le stazioni lia utilizzate sono state la: 05, 07, 08, 09, 10, cioe' le uniche funzionanti risparmiando il server (per evidenti ragioni di sicurezza, durante le prove infatti e' capitato di bloccare in maniera irreparabile le ws) ed una stazione per eventuali utenti.

Come considerazione finale vorrei porre l'accento sulla scelta riguardante C come linguaggio per realizzare il progetto.

Scelta che si e' rivelata poco consona agli scopi che il progetto si prefiggeva, ma anche poco pratica da un punto di vista implementativo.

Appare evidente che una soluzione in Java avrebbe prodotto una migrazione piu' trasparente ed indipendente dall'architettura, consentendo una portabilita' del codice in un ambiente diverso dalle sun del laboratorio.

Ho scelto di lavorare in C perche', quando ho iniziato il progetto, era il linguaggio che meglio conoscevo e che gia' avevo avuto modo di provare in precedenti corsi.

La complessita' del C , se da un verso ha significato un grosso scoglio nel verificare il codice dopo averlo compilato, da un altro ha pero' rappresentato l'occasione per meglio conoscere un sistema unix, al contrario di java che, offrendo una piattaforma virtuale, avrebbe garantito una maggiore astrazione.

Ipotesi implementative | Soluzione implementativa | Guida al codice | Considerazioni

Torna alla pagina di presentazione