Capitolo 2 Percorso di caricamento: chunk, concorrenza e ripresa (chiave)
Sul lato del caricamento, l'obiettivo è avvicinarsi il più possibile alla «saturazione della banda» con reti variabili, riducendo al minimo il costo degli errori (si ritrasmettono solo i chunk falliti). Insieme, questi due obiettivi spiegano in gran parte perché i caricamenti sembrano più veloci.
2.1 Suddivisione in chunk
- Il client DEVE dividere il file in più chunk; un chunk è l'unità minima per caricamento e nuovo tentativo.
- I chunk DOVREBBERO avere una dimensione fissa (o una dimensione scelta in base al file) per semplificare la pianificazione della concorrenza e la rappresentazione dello stato.
- Vantaggio immediato: qualsiasi errore riguarda un solo chunk, non l'intero file.
2.2 Caricamento parallelo
Lo scopo della concorrenza non è avere «più thread», ma evitare tre limiti pratici di una singola connessione nelle reti reali:
- Slow start e crescita della finestra: una singola connessione accelera lentamente, soprattutto con un RTT elevato tra regioni.
- Jitter del collegamento: il jitter su una connessione può far calare la velocità complessiva; la concorrenza ne attenua l'effetto.
- Traffic shaping per flusso: alcune reti limitano un singolo flusso; più flussi possono avvicinarsi di più al massimo della banda (nel rispetto dei vincoli di conformità).
- Il client DOVREBBE usare una concorrenza limitata (ad es. 4–12) e ridurla sui dispositivi più deboli per evitare picchi di memoria.
- Il client PUÒ adattare la concorrenza: aumentarla quando il throughput cresce, ridurla quando cresce il tasso di errore.
2.3 Idempotenza e nuovi tentativi
- Il caricamento ripetuto dello stesso chunk DEVE essere idempotente: gli invii duplicati non devono corrompere uno stato già completato.
- Il server DOVREBBE garantire l'unicità con (transferId, fileId, chunkIndex) o un vincolo equivalente.
- Il client DEVE implementare nuovi tentativi con backoff esponenziale; in caso di errore si DOVREBBERO ritentare solo i chunk falliti.
2.4 Caricamento riprendibile
- Il server DEVE poter rispondere alla domanda «quali chunk sono già stati caricati», così che il client possa saltare quelli completati.
- L'insieme dei chunk caricati DOVREBBE essere rappresentato come bitmap o insieme di intervalli, per evitare che la dimensione dello stato cresca in modo lineare con il numero di chunk.
- Vantaggio in termini di velocità: dopo interruzioni di rete, arresti anomali del browser o cambi di rete, la ripresa non riparte da 0%.
2.5 «Condividi mentre carichi» (facoltativo)
- Il sistema PUÒ generare un identificativo di trasferimento utilizzabile e un link di condivisione mentre il caricamento è ancora in corso, per accelerare i flussi di consegna.
- Se la condivisione è consentita prima del completamento del caricamento, DEVE essere chiaro cosa vedono i destinatari: il contenuto incompleto non è ancora scaricabile oppure viene mostrato solo l'avanzamento.