Chapitre 3 Chemin de téléchargement : téléchargement parallèle, récupération et réassemblage (clé)
Pour les destinataires, « plus rapide » apparaît principalement de deux manières : récupérer plusieurs morceaux en parallèle pour améliorer le débit et être capable de récupérer sous des réseaux faibles ou une commutation de réseau sans redémarrer. D'un point de vue technique, le chemin de téléchargement est symétrique au chemin de téléchargement.
3.1 Télécharger les objets et le manifeste
- Avant le téléchargement, le client DEVRAIT récupérer le manifeste pour connaître le nombre total de morceaux, l'ordre et comment localiser chaque objet.
- Le manifeste DOIT localiser de manière unique chaque morceau (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 morceaux 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.
- L'avantage de la concurrence est souvent plus important avec un RTT inter-régions élevé, car une seule connexion est plus facilement limitée par le RTT et la gigue.
3.3 Téléchargement avec reprise
- Le client DOIT être capable d'enregistrer l'ensemble des morceaux terminés (par exemple, un ensemble de bitmaps/index).
- Après une interruption, le client DEVRAIT récupérer uniquement les morceaux manquants, et non retélécharger l'intégralité du fichier.
- Si le serveur applique des limites de nombre de téléchargements, le client DEVRAIT minimiser les téléchargements redondants pendant la récupération pour éviter de gaspiller des comptes.
3.4 Remontage
- Le client DOIT réassembler le fichier de sortie dans l'ordre chunkIndex.
- Le client DEVRAIT utiliser les écritures en streaming/réassemblage progressif pour réduire les pics de mémoire (en particulier pour les très gros fichiers).
- Si plusieurs fichiers sont empaquetés, le client PEUT sortir par fichier ou utiliser un format de conteneur (en fonction de la conception du produit).
3.5 Contrôles d'intégrité (court)
- Après le téléchargement, le client DEVRAIT vérifier les morceaux (par exemple, cohérence hachage/longueur).
- Si la vérification échoue, elle DOIT échouer et réessayer le bloc correspondant.
- Pour connaître les limites autour des échecs de chiffrement/d’authentification, consultez les sections pertinentes du livre blanc sur la sécurité et la confidentialité.