Premetto che non ho mai lavorato con le DatagramSocket, ma il problema è di fondo. Il server non ha alcun accesso al file originario (che risiede sulla macchina client: è il client che glielo deve inviare, quindi il server non lo conosce, non conosce nulla di questo file e, chiaramente, non vi può "accedere" perchè, di fatto, sul server quel file non esiste).
Questa problematica (che c'è anche con le classiche Socket TCP), si risolve pensando ad un "protocollo" di comunicazione. Un esempio banale: ciascun pacchetto sarà composto da una stringa che indica il tipo di pacchetto, da un intero che indica il "contatore progressivo" di pacchetti di quel tipo e un'array di byte.
1) Il client, per prima cosa, invia al server una richiesta di "inizio trasferimento". Sarà un pacchetto contenente, ad esempio, "START_FILE" nella prima stringa, 0 nel valore intero (tanto non ce ne saranno altre), e, magari, il nome del file come array di byte.
2) Poi, il client inizia ad inviare una serie di pacchetti, ciascuno contenente "DATA_FILE" nella stringa (che indica che si tratta di un pacchetto dei dati del file), un valore progressivo come nel valore intero e il blocco di N byte letti dal file (ad esempio, un blocco di 1024 byte). Il client, in questa fase, sta leggendo il file a blocchi di 1024 byte e continuerà ad inviare pacchetti di questo tipo finchè non avrà letto tutto il file. Dopo ciascuna lettura, dovrà incrementare il valore intero da passare. Quindi, al server verrà inviata una sequenza di pacchetti come questa:
codice:"DATA_FILE", 0, { ... } // Primo pacchetto dati inviato "DATA_FILE", 1, { ... } // Secondo pacchetto dati inviato "DATA_FILE", 2, { ... } // Terzo pacchetto dati inviato ...
(tra le graffe ci saranno i byte di dati)
3) Raggiunta la fine del file ed inviato l'ultimo pacchetto dati, il client invierà al server un pacchetto con, ad esempio, "END_FILE" nella prima stringa, il numero di pacchetti inviati nel valore intero e un array di byte vuoto. In questo modo il server può sapere esattamente quanti pacchetti deve aspettarsi e può, eventualmente, controllare di averli ricevuti tutti.
Supponiamo, quindi, di voler trasferire il file "pippo.txt", di 5 KB. Il client invierà questa sequenza di pacchetti:
codice:"START_FILE", 0, {'p','i','p','p','o','.','t','x','t'} "DATA_FILE", 0, { ... } // 1° pacchetto dati inviato "DATA_FILE", 1, { ... } // 2° pacchetto dati inviato "DATA_FILE", 2, { ... } // 3° pacchetto dati inviato "DATA_FILE", 3, { ... } // 4° pacchetto dati inviato "DATA_FILE", 4, { ... } // 5° pacchetto dati inviato "END_FILE", 5, {}
Il server, di conseguenza, dovrà "regolarsi": il protocollo UDP non garantisce né che un pacchetto arrivi a destinazione, né che i pacchetti inviati siano ricevuti nell'ordine... quindi è il server che deve sobbarcarsi tutto il lavoro: deve ricevere i pacchetti, capire di che tipo di pacchetto si tratta (potrebbe ricevere, per primo, il pacchetto numero 3 dei dati, ad esempio), e trattarlo di conseguenza.
Ora, io non so perchè tu debba per forza usare UDP al posto del più pratico TCP... ma se usi UDP devi sottostare alle sue regole... quindi, sei tu che devi farti carico di ricevere i pacchetti, riordinarli e, alla fine, scrivere il file.
Se usassi TCP sarebbe tutta un'altra musica... rimane il fatto che il server, anche in questo caso, non ha a disposizione un FileInputStream, ma è agevolato dal fatto che i pacchetti sono sicuramente ricevuti in ordine e "garantiti"... quindi è tutto più semplice.
Ciao.![]()



Rispondi quotando
