Chapitre 3 Chemin de téléchargement : téléchargement parallèle, reprise et réassemblage (point clé)
Pour les destinataires, « plus rapide » se manifeste surtout de deux façons : récupérer plusieurs blocs en parallèle pour améliorer le débit, et pouvoir reprendre sur un réseau faible ou lors d’un changement de réseau sans tout recommencer. Du point de vue de l’ingénierie, le chemin de téléchargement est symétrique du chemin d’envoi.
3.1 Objets de téléchargement et manifeste
- Avant le téléchargement, le client DEVRAIT récupérer le manifeste pour connaître le nombre total de blocs, leur ordre et la façon de localiser chaque objet.
- Le manifeste DOIT localiser chaque bloc de façon unique (via des règles de clé d’objet ou un index équivalent).
3.2 Téléchargement parallèle
- Le client DEVRAIT télécharger plusieurs blocs simultanément pour se rapprocher du plafond de bande passante.
- Le client DEVRAIT utiliser une concurrence limitée et la réduire lorsque les taux d’erreur augmentent.
- Le bénéfice de la concurrence est souvent plus important lorsque le RTT inter-régions est élevé, car une connexion unique est plus facilement limitée par le RTT et la gigue.
3.3 Téléchargement avec reprise
- Le client DOIT pouvoir enregistrer l’ensemble des blocs terminés (par ex. bitmap ou ensemble d’index).
- Après une interruption, le client DEVRAIT récupérer uniquement les blocs manquants, et non retélécharger tout le fichier.
- Si le serveur applique des limites de nombre de téléchargements, le client DEVRAIT réduire au minimum les téléchargements redondants lors de la reprise afin de ne pas gaspiller de décomptes.
3.4 Réassemblage
- Le client DOIT réassembler le fichier de sortie dans l’ordre de chunkIndex.
- Le client DEVRAIT utiliser des écritures en flux (streaming) ou un réassemblage progressif pour réduire les pics de mémoire (notamment pour les très gros fichiers).
- Si plusieurs fichiers sont regroupés, le client PEUT produire chaque fichier séparément ou utiliser un format conteneur (selon la conception du produit).
3.5 Contrôles d’intégrité (bref)
- Après le téléchargement, le client DEVRAIT vérifier les blocs (par ex. cohérence du hachage et de la longueur).
- Si la vérification échoue, il DOIT échouer de façon sécurisée (fail closed) et réessayer le bloc concerné.
- Pour les limites relatives aux échecs de chiffrement ou d’authentification, consultez les sections correspondantes du livre blanc sur la sécurité et la confidentialité.