[java] invio di file tramite socket, salva i dati sul disco?

[gepeppe]

Salve, ho una curiosità su Java e la programmazione client-server. Ho un client e un server; dal client invio 2 file di testo, tramite le socket (quindi leggo il file tramite un programma che gira sul client, e invio i singoli byte del file) al server;

quest'ultimo salverà la sequenza di byte in 2 variabili stringa, e in seguito potrò accedere al "contenuto" del file usando soltanto quelle variabili. Facio un esempio sempice...se voglio creare un file di testo contenente il contenuto delle 2 variabili.

In questo pocesso di copia, i dati trasferiti dal client al server non verranno mai salvato sul disco, ma al massimo nella stessa area di memoria ram che il sistema stà riservando a java in quel momento. E' corretto come ragionamento???

[ally]

...se travasi i byte nella stringa di volta in volta nulla viene scritto...consiglio l'uso di un buffer piu' efficente al posto della String...sopratutto se non conosci la dimensione del file di test da inviare/ricevere...

...ciao Andrea...

[fero86]

non ho capito niente, specialmente non ho capito cosa c'entrano i socket e perché i file di testo sono due, ma tieni presente che il sistema potrebbe decidere di mettere in swap il contenuto delle stringhe.

[nuovoUtente86]

di norma (poi dipende dal SO) i dati vengono prima piazzati nel buffer del DMA della scheda di rete (se non utilizzi adattatori usb) e poi ricopiati nella variabile stringa del processo jvm. Parliamo di dati volatili, ma nulla impedisce al SO di paginare sul disco quelle locazioni, soprattutto se il sistema ha poca ram.

[gepeppe]

Ok mi spiego meglio

Devo creare un'applicazione client server. Il client deve inviare 2 file A e B al server. Questi 2 file sono stati creati a partire da un certificato utente x509 .p12. Non vorrei inviare il file p12 al server, per evitare che qualcun altro possa copiarlo, e per fare in modo che quest'ultimo rimanga sempre in possesso del client, sulla sua macchina Per questo motivo io creo questi file A e B (creati tramite la funzione opensso di java mi pare) invio questi 2 file al client che creerà un terzo file a partire da questi 2.

Per inviare i dati dal client al server devo utilizzare le socket..o c'è qualche altro metodo??

Adesso, il client invia i byte del primo file al server, che li memorizza in un buffer (come mi è stato fatto notare, soluzione migliore ). Una volta riempito tutto il buffer lo salvo in una stringa (e faccio lo stesso anche per l'altro file).

Adesso, l'ultima operazione è creare il 3° file dai 2 che ho prelevato dal buffer.

La cosa principale è evitare che i 2 file prelevati dal client vengano salvati sulla memoria del server...ma al massimo restano nella ram e nelle variabili di java..

ho cercato di essere più chiaro possibile..altrimenti riscrivo

[PGI-Bis]

Come ragionamento no, in pratica nì.

Ci sono due motivi per cui il ragionamento non fila. Quello certo è che la memoria assegnata ad un processo potrebbe risiedere sul disco fisso. Il famigerato "swap" ne è un sintomo.

Quella ipotetica è una questione di contratti. Il socket delle librerie standard di Java è l'astrazione di una connessione di rete e il contratto di quell'astrazione dice grossomodo: mi connetto e ti consento di trasferire dati attraverso dei flussi.

Quel che capita ai dati tra durante l'invio non è specificato. Sarebbe perfettamente ammissibile ancorchè bizzarra un'implementazione di Socket il cui flusso usasse un pezzo del disco come tampone.

Il ragionamento è in parte valido per una specifica versione di Java. Data la disponibilità dei sorgenti uno può lecitamente affermare che nell'implementazione di Java OpenJDK 6 b19 la ricezione di dati attraverso dei Socket non comporti la scrittura di quei dati sul disco fisso da parte della piattaforma Java.

Resta sempre il problema dello swap.

[ally]

...ok...ma qui il problema non è piu' Java...ma tutta la struttura interessata nel trasferimento...

...ciao Andrea...

[PGI-Bis]

Be' alla fine sì. Il discorso che vale per java.net.Socket vale anche per le sue controparti native.

Il fatto è che la preoccupazione che qualcosa non venga "fissato" sul disco fisso sa tanto di un problema di sicurezza e di sicurezza, come si dice, non se ne può fare "un po'", o si fa tutta o non si fa.

[gepeppe]

Si un po è un problema di sicurezza....Ora vi spiego tutto il problema.
l'utente per poter fare delle operazioni sul server, deve avere un certificato X509. Partendo da questo certificato, una volta inserita una password sua personale, si vengono a creare 2 file userkey.pem e usercert.pem

Una volta ottenuti questi 2 file, tramite un comando (che è possibile dare soltando dalla machina server) creo un file chiamato proxy..e grazie a questo proxy si riesce ad usare il sistema.

Adesso, io vorrei fare in modo che l'utente sulla sua machina avvii un programma che gli chiede di inserire la password e il percorso del certificato; in questo modo sulla sua machina sempre mi creo i file userkey.pem e usercert.pem, prendo questi file e tramite le socket li invio al server, che mi crea il proxy e poi "svuota" il contenuto delle variabili/buffer.

Per problemi di sicurezza appunto vorrei evitare di salvare il certificato sul server, cosi come le chiavi pem..ed è per questo che penso sia più sicuro che queste chiavi risiedano per pochi secondi in memoria ram (come contenuto di un buffer) piuttosto che come file nel server (a cui accedono molti utenti).

Correggetemi se il ragionamento è errato....prendere questo certificato p12 e salvarlo sul server, e da questo creare i file pem e infine il proxy, per poi eliminare il p12 e i pem, mi sembra un'operazione più "rischiosa"...

[gepeppe]

up