Newsgroup: it.comp.programmare.win32
Titolo: Spedizione di una immagine via tcp/ip

Il protocollo tcp/ip consente di spedire stringhe di caratteri con la
funzione send(). Come si puo' spedire una immagine (es Jpeg)?

 funzione send(). Come si puo' spedire una immagine (es Jpeg)?
E' una battuta, vero?
In questo caso: ahahah
Nell'altro: ???
Kiuhnm

Scusa, non volevo offendere la tua sensibilita`.

 Scusa, non volevo offendere la tua sensibilita`.
Hai scritto:
"Il protocollo tcp/ip consente di spedire stringhe di caratteri con la
funzione send(). Come si puo' spedire una immagine (es Jpeg)?"
TCP/IP invia i caratteri cosě come sono, giusto? Per intenderci non elimina
il bit alto o cose del genere, quindi che differenza c'č tra un carattere e
un byte?
Secondo te,
0x67, 0x4f, 0x68, 0x62
fa parte di un testo, di un file audio (mp3) o di una immagine (jpg)???
Non farti fuorviare dal fatto che il prototipo usi char *:
int send(
  SOCKET s,
  const char* buf,
  int len,
  int flags
);
Kiuhnm

 funzione send(). Come si puo' spedire una immagine (es Jpeg)?
CreateFile per aprire il file, GetFileSize per ottenere le dimensioni 
[1], CreateFileMapping per caricarlo in memoria, e infine MapViewOfFile 
per mapparlo in memoria. L'indirizzo ritornato da MapViewOfFile punterà 
ad una stringa con il contenuto del file, che puoi passare direttamente 
a send
[1] se il file è più grande di 2^32 byte (4 GB), non sarà così 
automatico. Dovrai trasferirlo a (e quindi mappare con MapViewOfFile) 4 
GB alla volta (o anche meno, perchè ne hai solo 2 a disposizione, e una 
certa parte è già in uso dal tuo programma). Insomma, metti un limite 
superiore alle dimensioni di un file trasferibile in questo modo
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 [1],
...[CUT]
Wheeeeeeeeeee che spreco! ;))
/********** -> Versione semplice ma funzionante (premesso che la parte
client sia gia' implementata)
Non e' portabile solo per la chiamata send() (sotto unix send ha un
parametro in meno)
*/
int Inviafile(stirng file, SOCKET desc){
    ifstream Sorgente (file.c_str());
    char temp[256];
    if(!Sorgente.is_open()) return 0;
    while(!Sorgente.eof() ){
        Sorgente.getline(temp,255);
        send(desc, temp,255,0);
    }
return 1;
}
//***************
Joshi

         send(desc, temp,255,0);
Ma
send ( desc, temp, strlen(temp),0);
scusate :-p
Joshi

         send(desc, temp,255,0);
getline???????
Guarda che questa funzione (con 2 soli parametri) legge fino al primo endl:
non è detto che legga sempre 255 caratteri.
E se le righe sono più lunghe di 255?
E poi rileggi l'oggetto del thread :-)
Devi usare la funzione 'read' in modalità binaria.
Kiuhnm

 Devi usare la funzione 'read' in modalità binaria.
Non cambia assolutamente nulla. Il file viene letto brutalmente, e
brutalmente spedito pari pari.
Quello che si trova da un lato viene riportato dall'altro. I byte di un file
li posso leggere sia binariamente che come char, il loro valore e' il
medesimo, il formato e il contenuto non vengono alterati.
Joshi

 Gia' gia'. Funziona anche getline.
Pensavo che getline troncasse la linea corrente a 255 e poi ripartisse dalla
successiva, invece ho visto che non č cosě (non uso le classi c++
solitamente)
Comunque, come hai giustamente notato, mancano tutti i "\n" (e pensare che
in un file binario non ce ne siano č veramente da ottimisti).
Il metodo piů efficiente č senz'altro quello di usare CreateFile e ReadFile
(eviterei CreateFileMapping e MapViewOfFile).
Getline invece č inefficiente perchč esegue continuamente un confronto tra
il carattere corrente e "\n".
Kiuhnm

 ReadFile (eviterei CreateFileMapping e MapViewOfFile).
già, poi però, chissà perchè, tutti finiscono per riscrivere i propri 
programmi per fare uso del mapping perchè è misteriosamente più veloce


 programmi per fare uso del mapping perchè è misteriosamente più veloce
Nel nostro caso Il mapping è inefficiente per vari motivi:
a) tutte le pagine del file devono essere inviate quindi il mapping deve
swappare una pagina dopo l'altra dall'inizio alla fine (il mapping è ottimo
per l'accesso casuale).
a2) gli accessi al disco non sono minimizzati in alcun modo.
b) il file è più grande della cache e quindi viene utilizzata la memoria di
sistema che è moooooolto più lenta (usando la cache su processori Athlon si
calcolano miglioramenti del 400%). Il buffer temporaneo ha invece un
indirizzo fisso e dimensioni arbitrarie.
c) Spreco di indirizzi logici/lineari (pensa a un file di 2 GB.....dove lo
metti???)
Comunque a meno di non possedere una connessione da 1 Gb, non si noteranno
rallentamenti, ma la questione cambia se l'immagine la si vuole copiare
direttamente nella memoria video.
Kiuhnm