DFGClient:

• In caso di caduta di DFGServer o della connessione con esso durante lo svolgimento del servizio o della ricezione della risposta, l'applet deve essere in grado di accorgersi del problema e segnalarlo all'utente. Non è prevista la terminazione del client, che deve dare la possibilità all'utente di attendere il ripristino del servizio e di riprovare.
• Nel caso di eccezioni durante la spedizione di un Messaggio_Interruzione, si chiude la connessione con DFGServer, si segnala l'errore e si continua l'esecuzione (non bisogna chiudere la connessione su cui DFGClient è in attesa dell'immagine, perchè questa operazione viene svolta dal punto precedente).

• In caso di caduta di DFGServer, al momento del suo ripristino bisogna prevedere il ripristino della sua Tabella in uno stato consistente. Questo avviene grazie ai messaggi di verifica della presenza di DFGServer che gli slaves spediscono ad intervalli di tempo regolari. Quando DFGServer riceve un messaggio di verifica da parte di uno slave non presente in tabella, approfitta di tale messaggio per effettuare la registrazione dello slave.
• In caso di impossibilità nello stabilire la connessione con uno slave o in caso di caduta di uno slave durante il servizio, il thread Esecutore corrispondente ritorna un messaggio di errore che provoca la cancellazione dello slave dalla Tabella e la ridistribuzione del lavoro tra gli altri slaves. Nel caso in cui lo slave cancellato sia l'unico slave presente, si deve comunicare al client che il servizio non è attualmente disponibile. Attenzione: la scelta di cancellare lo slave dalla Tabella non sempre è corretta: se la caduta della connessione con DFGSlave non è dovuta al fatto che lo slave è guasto ma solo ad un errore occasionale, la cancellazione dallo slave dalla Tabella è un'operazione concettualmente sbagliata. D'altra parte, il thread Esecutore non può sapere se lo slave è ancora in grado di svolgere il suo compito e la caduta della connessione con esso lo deve indurre a ritenere che non sia più "affidabile", quindi a cancellarlo dalla Tabella. Una cancellazione errata può portare ad anomalie nel funzionamento del sistema, ma solo se lo slave, al momento della sua cancellazione, sta calcolando altre immagini e se il completamento di tali immagini avviene dopo la spedizione del successivo Messaggio_Verifica a DFGServer. In tal caso, infatti, lo slave viene reinserito in Tabella col suo carico di default, che non corrisponde al suo carico effettivo. Per risolvere questo problema, sarebbe sufficiente far sì che i messaggi di verifica contenessero il reale valore di carico e non il carico di default.
• In caso di caduta del client o della connessione con esso, DFGServer non può accorgersi di nulla se non quando tenta di spedirgli l'immagine richiesta. Di conseguenza, per evitare uno spreco di risorse, nel caso l'utente voglia interrompere il calcolo di un'immagine non deve limitarsi a far terminare il client, ma deve premere il bottone "stop".
• Se un EsecutoreInterruzione non riesce a mettersi in contatto con lo slave per il quale è stato creato (ad esempio perchè nel frattempo lo slave è caduto) o se rileva eccezioni durante la spedizione del Messaggio_Interruzione, termina senza altre conseguenze.
• In caso di ricezione di un Messaggio_Registrazione da uno slave già presente in Tabella (dovuto ad esempio al fatto che lo slave è caduto mentre era inattivo ed è stato successivamente ripristinato), la sua Entry viene sostituita con quella contenuta nel messaggio. In questo modo è possibile modificare il carico di default di uno slave.
• Dopo che tutti i thread Esecutore sono terminati, bisogna eliminare il gruppo di thread che li conteneva (utilizzando il metodo setDaemon(true)). Questo è necessario per due motivi:
• mantenere in vita un oggetto quando è diventato inutile è uno spreco di risorse
• se un client spedisce, in tempi diversi, richieste di immagini utilizzando lo stesso numero di porta (questo può accadere in caso di caduta e successivo ripristino dell'host su cui esso risiede), viene creato un secondo gruppo di thread con lo stesso nome e non si riesce a trattare correttamente un'eventuale richiesta di interruzione.

• Guasto di un DFGSlave: se al momento della terminazione lo slave non sta calcolando nessuna immagine, DFGServer non si accorge della sua scomparsa. DFGServer si accorge della sua mancanza (e aggiorna di conseguenza la Tabella) solo quando tenta di utilizzarlo per un nuovo lavoro. Questo comporta un overhead (generazione di un thread, tentativo di stabilire una connessione e ridistribuzione del carico).
• In caso di caduta della connessione con DFGServer, lo slave si limita a rilevare l'eccezione e a liberare le risorse allocate a quella connessione.
• In caso di ricezione di un Messaggio_Interruzione relativo ad un GestoreMandelbrot non presente, non si fa nulla. Questa situazione può verificarsi se il calcolo dell'immagine termina prima che il messaggio di interruzione abbia il tempo di arrivare a DFGSlave e di essere eseguito.
• In caso di fallimento della procedura di registrazione, si continua ad effettuare periodicamente la richiesta di registrazione, in attesa che DFGServer venga ripristinato.
• In caso di fallimento della procedura di verifica della presenza di DFGServer, si interrompono tutti i thread GestoreMandelbrot attivi e si iniziano ad effettuare periodicamente richieste di registrazione, in attesa che DFGServer venga ripristinato.