ceccus ha scritto:Salve,
Allora, nel protocollo di trasmissione di rete , comunemente chiamato TCP , il concetto di controllo degli errori c'è sempre stato ... come c'è , ripeto, in qualsiasi tipologia di trasmissione digitale ... anche quando si trasmettono i dati in un Hard Disk passando per un "canale" ... questo vengono controllati e , se del caso, corretti.
Quindi , in una trasmissione di dati digitale, l' errore e la sua correzione sono "all' ordine del giorno".
E' vero, quando il pacchetto TCP/IP contiene errori che non possono essere corretti utilizzando i più comuni algoritmi , questo viene scartato e si richiede la sua trasmissione , in toto.
Una semplice lettura per comprendere determinati concetti : http://en.wikipedia.org/wiki/Error_detection_and_correction
Poi, l' ulteriore "problema" , nel cso di informazioni musicali, lo si ha quando dall' informazione digitale, ovvero in formato 0,1 , si passa alla sua rappresentazione analogica.
Con questo mio intervento NON sto dicendo assolutamente che tutto ciò che si riceve è "fallato" ... badate bene ... il mio intervento vuole essere uno "stimolo" per effettuare degli approfondimenti/ragionamenti che , forse, solitamente non si fanno ... o non si fanno più ...
Ciao !!
Anch'io parlo da ex-informatico.
penso che questa problematica sia grande ma applicabile solo in parte alla musica liquida :
forse dovremmo distinguere tra scaricamento di files, riproduzione di files via ethernet (per esempio da nas) o riproduzione streaming via http.
Nel primo caso penso che il file scaricato via TCP/IP sia esattamente uguale a quello originale : ci pensano i bit di parità a confermare o meno la validità dei pacchetti. É vero anche che teoricamente un doppio errore potrebbe valere come la doppia negazione in italiano, tuttavia è statisticamente impossibile che questo succeda quando il controllo si fa su array a 2 o più dimensioni (es. matrice di bit).
Questo non vuol dire che i pacchetti trasmessi siano sempre gli stessi ad ogni scaricamento : anzi questo è quasi impossibile e di solito i pacchetti non seguono lo stesso instradamento anche nella solita sessione e a volte non seguono nemmeno la giusta sequenza temporale ma arrivano mischiati ed è il layer preposto del ricevente a doverli mettere a posto.
D'altra parte il TCP/IP è nato per scopi militari proprio per questo : arrivare ad un risultato sicuro anche se da strade diverse, indipendentemente dal tempo necessario.
Secondo caso : la cosa è più semplice per il fatto che il nas di solito è su una LAN e quindi ci saranno evidenti minori problemi di instradamento.
Si introduce però il problema del tempo (cosa che nel primo caso non ha importanza); i pacchetti devono arrivare giusti ma anche entro un certo tempo, altrimenti il buffer del player si svuota e si sente a scatti, questo può succedere se la rete è limitata o wireless oppure con forte traffico o switchato male.
Terzo caso : il problema del tempo aumenta perchè la sorgente non è locale e quindi dipende anche dalla connessione o dal traffico generato sula rete.
In questo caso si possono perdere dei pacchetti perchè il traffico di solito viene gestito tramite non TCP ma UDP che è molto più snello e performante ma anche più "insicuro" : nei pacchetti infatti è inserito un tempo di estinzione, se il pacchetto raggiunge la scadenza viene abortito ovunque sia e non arriva a destinazione.
Basta pensare alla videoconferenza o ai video in streaming ; se un pacchetto audio/video arriva dopo un minuto a che serve ? al player gli è mancato quando ne aveva bisogno e quindi lo ha interpolato, se gli arriva dopo deve scartarlo e impegna la banda.
Cito dal link che hai postato :
UDP has an optional checksum covering the payload and addressing information from the UDP and IP headers. Packets with incorrect checksums are discarded by the operating system network stack. The checksum is optional under IPv4, only, because the IP layer checksum may already provide the desired level of error protection.
TCP provides a checksum for protecting the payload and addressing information from the TCP and IP headers. Packets with incorrect checksums are discarded within the network stack, and eventually get retransmitted using ARQ, either explicitly (such as through triple-ack) or implicitly due to a timeout.
Riguardo allo spoofing o peggio al man-in-the-middle, questi sono solo problemi che impegnano la banda e fanno perdere tempo ai dati.
Nel primo caso non dovrebbero esserci differenze ; d'altra parte anche se scarichiamo da più siti contemporaneamente oppure con applicazioni diverse, al ns. pc arrivano una marea di dati, ma saranno i giusti layer a indirizzarli sulle giuste porte logiche del pc.
Se parliamo di sicurezza il discorso è ben più ampio ma almeno con i files scaricati possiamo star sicuri (sempre che lo siano alla sorgente !!!!).
Quando leggete condite per favore tutto questo sproloquio con condizionali a volontà.
Felicissimo di essere smentito (anzi no, altrimenti saremmo messi proprio male
)
cordialmente. bwv544.
Indice
Pubblicazioni
Cerca
Ultime immagini
Registrati
Accedi
... uno "stimolo" in più , forse sbagliato, però recenti vicende , vedi Sony & C. ci dovrebbero far riflettere anche su DOVe andare a prendere certe "cosettine" ...
