Nello schema dello Slave vi è un Thread (SlaveAcceptMaster) dedicato all'accettazione delle richieste da parte del Master della propria rete locale via UDP. All'atto della creazione si pone in ascolto su una porta UDP dedotta dai parametri di ingresso. All'atto di una richiesta, se non si può accettare perché già raggiunto il numero massimo di richieste, viene restituita al Master la risposta di "Slave congestionato" , e, invece, se inferiore ad un dato valore di soglia, viene creato un Thread col compito di gestire la richiesta. Tale Thread ha quindi il compito di generare un Thread atto al soddisfacimento della stessa e di tornare in attesa di altre richieste
Il Thread generato (SlaveExeMaster) ha il compito di eseguire, come detto, la richiesta. Innanzitutto crea una porta UDP mediante la quale "informerà" a lavoro concluso il Master richiedente che i dati sono disponibili. In seguito legge i vari parametri dal pacchetto UDP di richiesta e, se TTL>0, istanzia un Thread (inoltraQueryMaster) che effettuera' il forwarding della stessa ad altri Master in modo identico a come avveniva per il Master nei confronti degli Slave (vedi). In ogni caso, anche con TTL=0, effettua una ricerca sul suo DB locale (non implementata in questo progetto). Alla fine della ricerca locale attende che il forwarding sia completato ( e tale attesa potrebbe essere molto lunga). A tal punto si effettua la solita operazione di compattazione e il risultato, se tutto è andato bene, è il nome del File.
Si invia (via UDP) un messaggio di "dati disponibili" al Master (che deve rispondere con un "ack") prendendo l'IP dal pacchetto di richiesta arrivato. Si crea poi una ServerSocket e si rimane in attesa che il Master si connetta per prelevare i dati. Si scrivono quindi i dati conclusivi sullo stream di Output della socket e si conclude l'operazione.
Alla fine
si aggiorna il contatore delle richieste da parte del Slave e si conclude la
sessione di lavoro;