This wiki, on valeriocipriani.com, uses cookies to give you the best experience on our websites. By continuing to use valeriocipriani.com, we assume that you accept our use of cookies.
Read more about cookies.
Dynamic Block Requests (DBR) (ita): Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
La procedura del download si sviluppa in questo modo: | La procedura del download si sviluppa in questo modo: | ||
*Viene effettuata una connessione al Peer e vengono determinati i chunk che il peer ha. | *Viene effettuata una connessione al Peer e vengono determinati i [[chunk (ita)|chunk]] che il peer ha. | ||
*Un Datarange viene riservato sul client locale per il download. Si tratta di una piccola parte del file. Lo stesso datarange non verrà richiesto ad altri peer. | *Un Datarange viene riservato sul client locale per il download. Si tratta di una piccola parte del file. Lo stesso datarange non verrà richiesto ad altri peer. | ||
*Lo stesso datarange è richiesto dal peer. | *Lo stesso datarange è richiesto dal peer. | ||
In questo modo richiedendo meno blocchi ai client lenti. possiamo richiedere maggiori/più grandi blocchi ai client più veloci che ci comporta di conseguenza una maggiore velocità di download e quindi un più veloce completamento del download. | In questo modo richiedendo meno blocchi ai client lenti. possiamo richiedere maggiori/più grandi blocchi ai client più veloci che ci comporta di conseguenza una maggiore velocità di download e quindi un più veloce completamento del download. | ||
Questa funziona ha senso solo se rimane una piccola parte del file/chunk da terminare. | Questa funziona ha senso solo se rimane una piccola parte del file/[[chunk (ita)|chunk]] da terminare. | ||
NOTA (a titolo informativo, non vale per la SharkX): | NOTA (a titolo informativo, non vale per la SharkX): | ||
Una precedente versione di questa funzione, includeva la "rimozione" delle fonti chge erano troppo lente in modo da permettere l'avanzamenti dei client più veloci. La rimozione delle fonti in questo caso non è una buona idea dat oche le fonti lente potrebbero diventare veloci in poco tempo, ad esempio si potrebbe essere assegnati ad un [[trickle slot]]. | Una precedente versione di questa funzione, includeva la "rimozione" delle fonti chge erano troppo lente in modo da permettere l'avanzamenti dei client più veloci. La rimozione delle fonti in questo caso non è una buona idea dat oche le fonti lente potrebbero diventare veloci in poco tempo, ad esempio si potrebbe essere assegnati ad un [[trickle slot (ita)|trickle slot]]. | ||
Revision as of 07:55, 19 May 2008
E' una tipologia di più veloce endgame di Netfinity, regolamenta la richiesta di blocchi, evitando eccessi, nel caso in cui il download stesse per concludersi.
La procedura del download si sviluppa in questo modo:
- Viene effettuata una connessione al Peer e vengono determinati i chunk che il peer ha.
- Un Datarange viene riservato sul client locale per il download. Si tratta di una piccola parte del file. Lo stesso datarange non verrà richiesto ad altri peer.
- Lo stesso datarange è richiesto dal peer.
In questo modo richiedendo meno blocchi ai client lenti. possiamo richiedere maggiori/più grandi blocchi ai client più veloci che ci comporta di conseguenza una maggiore velocità di download e quindi un più veloce completamento del download.
Questa funziona ha senso solo se rimane una piccola parte del file/chunk da terminare.
NOTA (a titolo informativo, non vale per la SharkX): Una precedente versione di questa funzione, includeva la "rimozione" delle fonti chge erano troppo lente in modo da permettere l'avanzamenti dei client più veloci. La rimozione delle fonti in questo caso non è una buona idea dat oche le fonti lente potrebbero diventare veloci in poco tempo, ad esempio si potrebbe essere assegnati ad un trickle slot.