Newsgroup: it.comp.programmare
Titolo: Sockets e trasmissione files di grandi dimensioni

Ciao NG
Non riesco a trovare granché in rete sul mio
problema e chiedo a voi. Non riesco a capire bene
come si posizionano i sockets nella gerarchia dei
livelli della comunicazione, dal collegamento fisico
al livello logico.
In particolare, volevo capire come si trasmettono
files grandi tramite i sockets. Tutte le funzioni
usano un buffer che può non avere la stessa
dimensione del file e mi aspetto che solitamente sia
molto più piccolo. Non vedo difficoltà a trasmettere
il file aprendolo in binario, dividerlo in sezioni,
posizionarmici sopra con fseek, riempire il buffer
ed effettuare le corrispondenti operazioni dal lato
ricezione per ricomporlo.
Ma mi chiedo: la trasmissione di ogni pacchetto, al
livello del socket è sicura? Ovvero, il socket è a
un livello di astrazione sufficiente a garantire che
quel che arriva è proprio quel che ho trasmesso o
sta al di sotto e quindi devo farmi carico io dei
controlli su ogni parte trasmessa per poter
ricomporre il file correttamente? Se è così, che
tecniche si usano?
grazie come sempre
Apx.
-- 
Perché gli iraniani odiano il vento?
Perché gli sbatte tutte le persiane.

 * Raw sockets (or Raw IP sockets), typically available in routers and other network equipment. Here the transport layer is bypassed, and the packet headers are not stripped off, but are accessible to the application. Application examples are Internet Control Message Protocol (ICMP, best known for the Ping suboperation), Internet Group Management Protocol (IGMP), and Open Shortest Path First (OSPF).


Grazie a entrambi! Diciamo che si tratta di qualche
centinaio di mega, forse massimo uno o due giga.
Visto quel che mi dite, potrei spezzettarlo e
controllare sezione per sezione. Ora su due piedi
pensavo a estrarre sequenze casuali di bytes da ogni
sezione e alla fine trasmissione di ogni sezione i
due lati si scambiano che so, un qualche hash su
ciascuna sequenza.
In fondo questa idea su due piedi non mi appare
nulla di più originale di una variante bastarda e
inefficiente del CRC fatta su spezzoni piccoli.
Altro non mi viene in mente ma sicuramente ci sarà
un po' di letteratura in giro e me la cercherò.
ciao!


 inefficiente del CRC fatta su spezzoni piccoli.
Perch� devi complicare le cose semplici? :)
Hai un file da 800 Mbyte? che granularit� di controllo vuoi avere? ogni
Mbyte? bene, manda 1 Mb per volta e accodagli il suo hash/crc. Le tecniche
ormai sono consolidate, non reinventare l'acqua calda. 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 a piï¿œ alto livello.
Non ho capito questo punto. Il controllo del CRC non viene fatto su ogni 
singolo pacchetto IP?
In quel caso se il trasferimento del singolo pacchetto ï¿œ affidabile, 
cosa cambia tra trasferirne pochi o migliaia? E' vero che il CRC del 
singolo pacchetto potrebbe fallire ma questo puï¿œ capitare sia su un file 
piccolo che su uno grande. O mi sfugge qualcosa?
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non ï¿œ valido)

 piccolo che su uno grande. O mi sfugge qualcosa?
Su migliaia e migliaia di pacchetti aumenta la probabilitï¿œ che il CRC di 
uno di essi fallisca, e che uno riceva dei dati errati prendendoli per 
veri. Tipicamente ci si accorge di ciï¿œ solo quando uno ha il file 
completo, dopo ore di download (mi ï¿œ successo) e prova ad aprirlo.
Non ï¿œ piacevole :-)

 Non ï¿œ piacevole :-)
Ok, ma il problema si presenta anche per file piccoli, soprattutto se ne 
trasferisci molti. Se devi fare un trasferimento sicuro al 100% allora 
devi considerare sempre la possibilitï¿œ di errore.


 centinaio di mega, forse massimo uno o due giga.
Ma perche' invece di reinventare la ruota non usi qualche protocollo e
libreria standard? A seconda del tipo di dati e di files possono esserci
scelte diverse, ma un ftp o un http  potrebbero essere un buon punto di
partenza. O magari tftp
Oppure usare qualche libreria di torrent. E' roba collaudatissima su
bestie dell'ordine di alcuni giga. Credo che anche con il minimo
overhead del protocollo, l'efficienza e l'affidabilita' del codice siano
molto superiori a quello che puoi mettere su in un tempo ragionevole.
E' possibile che ci siano protocolli ancora piu' indicati. 
Se per esempio ti trovi con altre esigenze, pensaci. Per esempio rsync
e' molto efficiente se hai spesso dati "duplicati" fra le
ritrasmissioni. Etc etc etc.
Poi ci sono i vari protocolli di streaming.
Io credo che nel 2010 farsi da 0 un mini-protocollo ad hoc dovrebbe
essere molto in basso nella valutazione di cose da fare.
-- 
-riko

 basso nella valutazione di cose da fare.
Mi tocca quotare tutto :) Certo che è come dici, ma
il mio problema, e credo non solo mio, è che ormai
c'è fin troppo. Le stesse ricerche con gugl ormai
presuppongono che si sappia cosa cercare. Ho cercato
librerie ma esce roba stranissima. Mi scoccia
rompere con ogni piccolo ostacolo che incontro e non
ho chiesto quali librerie potessi usare, ma forse
facevo prima a farlo.
E so bene che il trasferimento di files è un
pezzetto di una cosa che vorrei fare e che a sua
volta sicuramente esiste già, un piccolo database
ridondante su diversi server. Lo fa MySQL a
pagamento ma il problema è sempre il solito: ormai
l'informatica è così complessa che 1) o si è
lavorato su quel tema specifico o 2) le ricerche e
successive prove alle volte portano via quasi
altrettanto tempo che riscriversi tutto da sé (nel
caso specifico, userei SQLite che è self contained,
lo conosco e ci sono i sorgenti, e ogni transazione
la spedisco su più servers; in caso di crash uso il
database più recente rispedendone una copia agli
altri servers, di qui il "come spedire grossi files").


 altri servers, di qui il "come spedire grossi files").
Con giga di roba, hai detto?
Oh, buona fortuna.
Scroprirai che il problema "e' un po' piu' complesso" di quanto sembra.

 pagamento ma il problema � sempre il solito:
Senza entrare in "disputa", io starei abbastanza lontano da MySQL. 
it.comp.lang.python e' pieno di post che motivano questa affermazione.
-- 
-riko

Senza entrare in "disputa", io starei abbastanza lontano da MySQL. 
Anche perch�, a dispetto di ci� che pensano molti, per usi commerciali
ci vuole la licenza. Io sto usando PostgreSQL per tutti i miei
progetti e mi trovo molto bene.

 progetti e mi trovo molto bene.
Per carità, non dovrei fare niente di commerciale,
solo calcolo scientifico. Ma sento sempre più parlar
male di MySQL e sempre meglio di PosgreSQL, non sei
il primo.


 devi considerare sempre la possibilitï¿œ di errore.
Vero, certo. Ma il punto ï¿œ che se ti si corrompe un file piccolo, 
ritrasmetterlo da capo quando te ne accorgi costa poco o nulla, invece 
ritrasmettere una ISO da 2 GB ï¿œ una faccenda lunga. Meglio, molto meglio 
spendere un pï¿œ di banda e di CPU in piï¿œ ma fare in modo di trasmetterla 
bene al primo colpo...

 il primo.
Diciamo che � in nutritissima compagnia. E' che PosgtreSQL � fatto
*davvero* bene, viceversa MySQL � fatto *davvero* male. 
D'altra parte Monty si qualifica ogni giorno di pi�.
-- 
-riko