Link alla notizia: http://www.hwupgrade.it/news/software/nuovo-protocollo-per-bittorrent-supporto-al-throttling_30639.html

BitTorrent Inc. è prossima al rilascio di una nuova versione del proprio protocollo BitTorrent, in grado di avvantaggiare sia gli utenti sia gli ISP

Click sul link per visualizzare la notizia.

Il traffico torrent può creare problemi di occupazione della banda nel resto del pianeta ma non in Italia. Stando alle statistiche di speedtest.net siamo tra gli ultimi in europa e nel mondo civilizzato per banda disponibile in upload, 83° con 44kb/s in upload (in upload siamo 44°). Perciò ben vengano queste tecnologie che ottimizzano la congestione del traffico sulla rete, sperando ci sia la rete. E dire che ho una 8 mega che viaggia sempre, anche nel cuore della notte a 6,56 Mb/s in down ma in upload non supero i 55kb/s. E mi ritengo ultra:ciapet: abitando a Torino... quando sto in Calabria dai miei invece è una pena perchè tele2 (leggi vodafone) castra pesantemente il traffico torrent... Sarebbe meglio trovare un modo di offuscare completamente il protocollo...

Cavolo la tua Adsl va più forte della mia rete locale :D

secondo me invece gli ISP (in italia) dovrebbero smetterla di far finta che la loro rete sia sovradimensionata e pronta al futuro e adeguare gli impianti, cosicché nessuno avrà più velocità dell'altro (inclusi i problemi fisici centrale-utente).


vero


dire bisogna offuscare il protocollo == dire bisogna smetterla di impiegare carbone...

non ho compreso bene il paragone...


Cavolo la tua Adsl va più forte della mia rete locale :D

collegamento punto punto via rs232? :D che razza di ethernet ti ritrovi?

il 27% del traffico mondiale è usato da youtube.
Il 20% del traffico mondiale è usato dal p2p.

Chiudiamo youtube che utilizza troppe risorse?

Come si fa a modificare l'upload senza toccare il download? visto che l'upload di un utente rappresenta il download di un altro....

Esatto Gainder, proprio quello che stavo pensando io...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.

Come si fa a modificare l'upload senza toccare il download? visto che l'upload di un utente rappresenta il download di un altro....

la stessa domanda che mi sono fatto anche io

@Gainder
Non si tratta di diminuire l'upload "utile" ma di eliminare quello inutile, quello fatto di pacchetti che vengono persi e intasano la rete senza arrivare a destinazione.
Per capirci, quando ad uno dei router che formano l'infrastruttura della rete arrivano più pacchetti di quelli che è capace di smaltire (congestione) alcuni di questi verranno scartati.

Il protocollo TCP che normalmente usiamo per le connessione implementa un meccanismo per assicurare la ritrasmissione del pacchetto perduto ed anche un primitivo controllo della velocità per evitare che il numero di pacchetti persi salga troppo in caso di connessione davvero affollata. Il meccanismo di controllo del TCP è più che sufficiente nella stragrande maggioranza dei casi ma in connessioni ad alto traffico come quello p2p può rivelarsi inefficiente, per questo Bittorrent ha studiato un sistema di controllo più moderno ed efficiente che non fa uso di TCP ma di UDP.

Proprio in situazioni come quella Italiana, cioè linee scadenti e congestioni tremende in ora di punta, questa tecnologia darà i risultati migliori, o almeno si spera ;)

@Gainder
Non si tratta di diminuire l'upload "utile" ma di eliminare quello inutile, quello fatto di pacchetti che vengono persi e intasano la rete senza arrivare a destinazione.
Per capirci, quando ad uno dei router che formano l'infrastruttura della rete arrivano più pacchetti di quelli che è capace di smaltire (congestione) alcuni di questi verranno scartati.

Il protocollo TCP che normalmente usiamo per le connessione implementa un meccanismo per assicurare la ritrasmissione del pacchetto perduto ed anche un primitivo controllo della velocità per evitare che il numero di pacchetti persi salga troppo in caso di connessione davvero affollata. Il meccanismo di controllo del TCP è più che sufficiente nella stragrande maggioranza dei casi ma in connessioni ad alto traffico come quello p2p può rivelarsi inefficiente, per questo Bittorrent ha studiato un sistema di controllo più moderno ed efficiente che non fa uso di TCP ma di UDP.

Proprio in situazioni come quella Italiana, cioè linee scadenti e congestioni tremende in ora di punta, questa tecnologia darà i risultati migliori, o almeno si spera ;)

grazie della spiegazione

Se non ho capito male hanno aggiunto il congestion control al BitTorrent..
Ma BitTorrent usa UDP o TCP? perchè se fosse il secondo caso, sbaglio o il congestion control esiste già?
Fanno un -doppio- controllo della congestione, sia a livello rete che su rete overlay?

Non ho di questi problemi...il mio provider ha la rete congestionata anche senza usare torrent :O

W il download notturno :asd:

Esatto Gainder, proprio quello che stavo pensando io...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.

Sarebbe si bello peccato però che il multicast (perchè di multicast si tratta, non di broadcast) in internet per ora è implementato parzialmente e gestito in modo molto complesso percui di fatto poco attuabile...

secondo me invece gli ISP (in italia) dovrebbero smetterla di far finta che la loro rete sia sovradimensionata e pronta al futuro e adeguare gli impianti, cosicché nessuno avrà più velocità dell'altro (inclusi i problemi fisici centrale-utente).
In Giappone vanno a 160Mbps a 44€ al mese... :muro:

collegamento punto punto via rs232? :D che razza di ethernet ti ritrovi?
No, è che hai scritto che la tua ADSL va a 6,56 Mb/s e lui ha inteso MB (MegaByte) invece di Mb (Megabit) :asd:

Come si fa a modificare l'upload senza toccare il download? visto che l'upload di un utente rappresenta il download di un altro....
Non viene toccata la gestione del Download, viene semplicemente migliorata la gestione dell'Upload, di conseguenza dovrebbe anche migliorare il Download, in teoria...

I cosiddetti ISP (Internet Service provider), le compagnie che offrono accesso ad internet, si sono trovate da tempo a dover affrontare il problema legato a BitTorrent e alle grandi risorse in termini di banda che questi client richiedono.

Oh ma poverini :doh:

Ma che vadano anche un pò a quel paese, dico io, fino a prova contraria la banda la PAGHIAMO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Cos'è, ora manco quello per cui paghiamo ci danno?????????


Boh, mistero.. questa funzione riduce l'uso di banda? Bene, ma se è per l'utente :rolleyes:

Bittorrent usa TCP di default, ma può anche essere impostato per usare UDP.

Il problema è appunto che TCP controlla che il pacchetto arrivi altrimenti lo rimanda, ma in bittorrent non è necessario dato che lo fa già il client torrent, quindi usando UDP si elimina il doppio controllo e si aumenta la velocità. UDP però, al contrario di TCP, non ha nulla per controllare e adattarsi alla congestione delle rete, e se tutti avessero usato bittorrent con udp le reti si sarebbero congestionate..

Così per risolvere hanno creato un UDP+ o un TCP-, nel senso che si tratta di un UDP con in più controllo della congestione di rete o di un TCP senza il controllo di integrità dei pacchetti..

Questo è quello che a grandi linee lessi su una rivista tempo fa..

Ma cosa vuoi congestionare, che ogni utente ha upload e download limitati :D

ma nel protocollo TCP/IP c'è già il controllo sulla congestione... O_O

Bittorrent usa TCP di default, ma può anche essere impostato per usare UDP.

Il problema è appunto che TCP controlla che il pacchetto arrivi altrimenti lo rimanda, ma in bittorrent non è necessario dato che lo fa già il client torrent, quindi usando UDP si elimina il doppio controllo e si aumenta la velocità. UDP però, al contrario di TCP, non ha nulla per controllare e adattarsi alla congestione delle rete, e se tutti avessero usato bittorrent con udp le reti si sarebbero congestionate..

Così per risolvere hanno creato un UDP+ o un TCP-, nel senso che si tratta di un UDP con in più controllo della congestione di rete o di un TCP senza il controllo di integrità dei pacchetti..

Questo è quello che a grandi linee lessi su una rivista tempo fa..

Capito...
Mi pare che esista già qualcosa del genere rimanendo a livello di rete senza coinvolgere il protocollo bittorrent, mi pare si chiami DCCP, che integra un meccanismo di congestion control, è connection oriented come il tcp (3-way handshake per l'istaurazione e il teardown), e con header corto e semplice per essere veloce come l'UDP... ma non so quanto sia diffuso (è un protocollo abbastanza nuovo, l'rcf dice 2006) ad oggi!

Mah, dal mio modestissimo punto di vista prima di mettersi ad abbassare le velocità avrebbero dovuto provare ad applicare l'idea del p4p, e cioé una geo-localizzazione dei peer e, quindi, una diminuzione della distanza e dei nodi per cui il pacchetto deve passare, riducendo appunto anche la congestione. :)

Esatto Gainder, proprio quello che stavo pensando io...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.

Aka usare tutti l'IPV6. Ottima idea, Arrows! :eek:
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica. :)

Cavolo la tua Adsl va più forte della mia rete locale :D

:rotfl: :rotfl: :rotfl:

...ma LOL

Aka usare tutti l'IPV6. Ottima idea, Arrows! :eek:
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica. :)

Domanda. Perché implementare ipv6? Quali vantaggi darebbe?

da piccolo giocavo a throttling throttling cavallino :O

Originariamente inviato da elevul Guarda i messaggi
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica. Domanda. Perché implementare ipv6? Quali vantaggi darebbe?

quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??

quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??

non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...

Il traffico torrent può creare problemi di occupazione della banda nel resto del pianeta ma non in Italia. Stando alle statistiche di speedtest.net siamo tra gli ultimi in europa e nel mondo civilizzato per banda disponibile in upload, 83° con 44kb/s in upload (in upload siamo 44°). Perciò ben vengano queste tecnologie che ottimizzano la congestione del traffico sulla rete, sperando ci sia la rete. E dire che ho una 8 mega che viaggia sempre, anche nel cuore della notte a 6,56 Mb/s in down ma in upload non supero i 55kb/s. E mi ritengo ultra:ciapet: abitando a Torino... quando sto in Calabria dai miei invece è una pena perchè tele2 (leggi vodafone) castra pesantemente il traffico torrent... Sarebbe meglio trovare un modo di offuscare completamente il protocollo...

E ti lamenti? :D
E io che devo navigare col cellulare.. sulla carta vanno più veloci della ADSL cablata terrestere.. nella realtà manco 1MBit/s! (se non salta direttamente in UMTS.. e ciao ciao) :asd:

Spiegatemi una cosa, visto che esistono 50 clients torrent differenti (se non di più) con diverse funzionalità, tra cui DHT;
come facciamo a sapere da quale versione e quali clients supporteranno questa nuova funzionalità del protocollo UTP???

Io uso abitualmente 3 Clients torrent (e sono quelli che ad oggi mi hanno dato maggiori soddisfazioni) su Win ovviamente.

In ordine di merito: µTorrent 2.10, BitSpirit 3.60 (che ha la patch integrata per portare le porte halfopen @256) e BitTirant (che però usa il Frame 2.0).

Come leggerezza µTorrent (200KB), consumo risorse esiguo e velocità rimane imbattibile a mio avviso,
poi nella scheda avanzate (advanced) è possibile migliorare i parametri interni del client P2P e farlo correre ancora di più (sono disponibili su youtube) basta cercare :D

Come si fa a sapere se i clients più utilizzati adotteranno questa nuova funzionalità? :mbe:

ma nel protocollo TCP/IP c'è già il controllo sulla congestione... O_O
No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.
Capito...
Mi pare che esista già qualcosa del genere rimanendo a livello di rete senza coinvolgere il protocollo bittorrent, mi pare si chiami DCCP, che integra un meccanismo di congestion control, è connection oriented come il tcp (3-way handshake per l'istaurazione e il teardown), e con header corto e semplice per essere veloce come l'UDP... ma non so quanto sia diffuso (è un protocollo abbastanza nuovo, l'rcf dice 2006) ad oggi!
Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.
Mah, dal mio modestissimo punto di vista prima di mettersi ad abbassare le velocità avrebbero dovuto provare ad applicare l'idea del p4p, e cioé una geo-localizzazione dei peer e, quindi, una diminuzione della distanza e dei nodi per cui il pacchetto deve passare, riducendo appunto anche la congestione. :)
non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...
Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.

In Giappone vanno a 160Mbps a 44€ al mese... :muro:

non c'e' bisogno di andare in estremo oriente, anche qui a Budapest ci sono quelle velocita' a quei prezzi..

io ho una 15Mbit/1.5Mbit a circa 16 euro al mese (pagati pure dalla compagnia dove lavoro :Prrr: )

vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...

vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...
Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).

Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!

No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.

Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.


Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.

visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione

Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!

ma quanto caxxo scarichi? :D

io ho gli hdd saturi :mc:

Magari non 24 ore consecutive, anche se a volte è capitato.... ma a qualsiasi ora inizio ci voglio quei 5 minuti per andare a regime e poi non si scosta mai dal 90% della banda disponibile.... e fino a quando avevo il router di alice queste velocità me le potevo solo sognare !!!

visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione
Perché gestire un peer che invia tanti messaggi a tanti altri peer è troppo complesso con TCP. Senza contare che, pur se l'overhead per un singola sessione TCP è piccolo, per una moltitudine di connessioni TCP è molto alto.
Le primitive messe a disposizione per UDP sono semplicissime: sendto e recvfrom e lavorano direttamente sugli indirizzi ip.
UDP permette quindi di personalizzare al massimo il protocollo, ecco perché viene usato in praticamente tutti i protocolli P2P.

ma quindi anche il controllo di errore viene fatto a livelli piu alti?

ma quindi anche il controllo di errore viene fatto a livelli piu alti?
Viene fatto il controllo di errore sul protocollo BitTorrent ?
Il controllo di errore che io sappia nel BitTorrent viene fatto a livello di chunks e non a livello di pacchetto. Quindi se una volta che il chunk viene completato il fingerprint è errato, il chunk viene eliminato e richiesto nuovamente ai peer.
Quindi nel protocollo non solo non c'è la correzione dell'errore, ma nemmeno la possibilità di verificare la presenza di un errore.

UDP ha un checksum, addirittura credo che possa venire ignorato (trasmettendo tutti 1) oppure semplicemente viene riportato un errore del checksum al ricevente. Il problema è che il ricevente, a meno che non abbia una singola sessione UDP aperta, non può affidarsi al pacchetto con checksum errato per determinare l'indirizzo ip dal quale proviene il pacchetto, infatti il checksum è calcolato sul pacchetto UDP e su parte dell'header IP (compresi gli indirizzi). Quindi anche l'indirizzo IP potrebbe essere errato ;)

Il nuovo sistema di controllo di congestione sembra che si affidi ad un semplice timestamp per la stima del round trip time. Imho ci saranno due campi in più nel protocollo BitTorrent, un bit da mettere ad 1 che attiva uTP ed un campo opzionale in cui andare ad inserire il timestamp del mittente.
Il ricevente quando trova il campo uTP ad 1 prende il timestamp e lo invia nuovamente al peer che lo aveva generato. In questo modo si riesce a stimare il tempo che ci impiega il pacchetto per andare ad un peer e tornare indietro. Ovviamente c'è congestione se questo tempo aumenta troppo o se la risposta non ritorna (entro un opportuno timeout proporzionale al RTT stimato precedentemente).

OK ho capito ma ricapitolando; la congenstione del traffico provoca la perdita dei pacchetti che devono essere inviati reiterate volte sul protocollo UDP, il quale non prevede nessun meccanismo anti-traboccamento. Il nuovo protocollo uTP permetterebbe di inviare intelligentemente i pacchetti agli utenti non saturi e limitare il reinvio agli utenti saturi.

Grazie a questo cosa migliorera?

La velocità di download dipende dalla velocità di upload dell'altro utente, quindi al massimo si scaricherà come ora. Xò il fatto di inviare i pacchetti alle persone giuste permette di incrementare le prestazioni solo nel caso di congestione. Questo protocollo infine non è per aumentare la velocità di download\upload in generale, ma specificamente nel caso in cui ci sia una congestione.

Staremo a vedere...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.
Indubbiamente andare in Multicast sarebbe molto più comodo per tutti, magari un giorno...

Aka usare tutti l'IPV6. Ottima idea, Arrows! :eek:
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica. :)
Ma penso che ci stiano già lavorando visto che presto (2011) si comincerà ad usarlo e non troppo più tardi (2025) l' IPv4 morirà...

Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).
Abito a neanche 500m in linea d'aria dalla centrale e godo solo di 13 mega su 20 che ne pago :muro:

Indubbiamente andare in Multicast sarebbe molto più comodo per tutti, magari un giorno...


Ma penso che ci stiano già lavorando visto che presto (2011) si comincerà ad usarlo e non troppo più tardi (2025) l' IPv4 morirà...

C'è da dire che se il protocollo torrent prevedesse obbligatoriamente l'utilizzo dell'IPV6( già è possibile usarlo attraverso Teredo) che, se non ricordo male, ha il multicast integrato di default, ci sarebbe una fortissima spinta per un più rapido aggiornamento al protocollo, e tutti ne beneficeremmo.

C'è da dire che se il protocollo torrent prevedesse obbligatoriamente l'utilizzo dell'IPV6( già è possibile usarlo attraverso Teredo) che, se non ricordo male, ha il multicast integrato di default, ci sarebbe una fortissima spinta per un più rapido aggiornamento al protocollo, e tutti ne beneficeremmo.
Beh l'IPv6 ora come ora è ancora in "sperimentazione" (periodo che dovrebbe finire nel 2011), certo che se la mettessero come opzione la userebbero tutti quelli che ci smanettano un minimo.

Cmq per chi volesse saperne qualcosa in più sull'IPv6 consiglio di guardare i seguenti link:
http://it.wikipedia.org/wiki/IPv6 da Wikipedia
http://www2.garr.it/ws5/pdf/Paolini-IPv6.pdf dal GARR (The Italian Academic & Research Network)

PS: con l'IPv6 i clienti FastWeb possono avere un IP Pubblico a Gratis. ;)

OK ho capito ma ricapitolando; la congenstione del traffico provoca la perdita dei pacchetti che devono essere inviati reiterate volte sul protocollo UDP, il quale non prevede nessun meccanismo anti-traboccamento. Il nuovo protocollo uTP permetterebbe di inviare intelligentemente i pacchetti agli utenti non saturi e limitare il reinvio agli utenti saturi.

Grazie a questo cosa migliorera?
No, questo protocollo permette di non saturare stupidamente il provider. La congestione non provoca problemi solamente al nostro client torrent:
- se non viene fatto traffic shaping provoca problemi a tutti le connessioni servite dal router
- se viene fatto traffic shaping, provoca problemi a tutte le connessioni servite dal router che rientrano nella stessa nostra classe di traffico (ad esempio tutti client torrent o tutto il traffico UDP) ed in quantità minore a tutte le altre connessioni

Usando le risorse del provider in modo più equo, ci saranno meno problemi di saturazione per il provider e quindi le nostre ADSL saranno sicuramente meno congestionate. In pratica il provider potrà servire altri tipi di traffico in maniera più efficiente. Diminuiranno i ping, ad esempio ci saranno mediamente meno problemi nelle ore di punta per il gioco online.

...con l'IPv6 i clienti FastWeb possono avere un IP Pubblico a Gratis...

Ni.

Ni.
Ni?

Nel senso che se l'indirizzo IP6 è ottenuto in tunneling, allora è vero (ma è un pò come se fossi in VPN con un'altra rete). Se è rilasciato da FastWeb no perchè comunque l'IPV6 prevede il NAT, anzi tecnicamente prevede qualcosa di più sofisticato ancora...

Nel senso che se l'indirizzo IP6 è ottenuto in tunneling, allora è vero (ma è un pò come se fossi in VPN con un'altra rete). Se è rilasciato da FastWeb no perchè comunque l'IPV6 prevede il NAT, anzi tecnicamente prevede qualcosa di più sofisticato ancora...
Ah ok, sì, quelli che dicevo io sono servizi di tunneling, poi ovviamente tale sistema avrà dei limiti immagino però porta anche i suoi vantaggi.

Quando ci sarà lo "switchover" per cui si passerà in massa ad usare IPv6 ed i provider smetteranno di dare IP IPv4 ai clienti (cioè molto in là visto che la massima parte dei dispositivi di rete domestici avrebbero bisogno di un upgrade) allora FW potrà dare un IPv6 pubblico (più probabilmente gliene daranno anche 256) a tutti (ma anche no, c'è da vedere che idea hanno quelli del settore commerciale).