Capítulo 3 Caminho de download: download paralelo, recuperação e remontagem (ponto-chave)
Para os destinatários, “mais rápido” aparece principalmente de duas formas: buscar vários blocos em paralelo para melhorar o throughput e conseguir se recuperar em redes fracas ou na troca de rede sem reiniciar. Do ponto de vista da engenharia, o caminho de download é simétrico ao caminho de upload.
3.1 Objetos de download e manifesto
- Antes de baixar, o cliente DEVERIA buscar o manifesto para saber a quantidade total de blocos, a ordem e como localizar cada objeto.
- O manifesto DEVE localizar cada bloco de forma única (por meio de regras de chave de objeto ou de um índice equivalente).
3.2 Download paralelo
- O cliente DEVERIA baixar vários blocos simultaneamente para chegar mais perto do teto de largura de banda.
- O cliente DEVERIA usar concorrência limitada e reduzi-la quando as taxas de erro aumentarem.
- O benefício da concorrência costuma ser maior quando o RTT entre regiões é alto, porque uma única conexão é limitada com mais facilidade pelo RTT e pelo jitter.
3.3 Download com retomada
- O cliente DEVE conseguir registrar o conjunto de blocos concluídos (por exemplo, bitmap / conjunto de índices).
- Após uma interrupção, o cliente DEVERIA buscar apenas os blocos que faltam, e não baixar o arquivo inteiro novamente.
- Se o servidor impuser limites de quantidade de downloads, o cliente DEVERIA minimizar downloads redundantes durante a recuperação para não desperdiçar contagens.
3.4 Remontagem
- O cliente DEVE remontar o arquivo de saída na ordem de chunkIndex.
- O cliente DEVERIA usar gravação em streaming / remontagem progressiva para reduzir os picos de memória (especialmente em arquivos muito grandes).
- Se vários arquivos forem empacotados, o cliente PODE gerar a saída por arquivo ou usar um formato de contêiner (conforme o design do produto).
3.5 Verificações de integridade (resumo)
- Após o download, o cliente DEVERIA verificar os blocos (por exemplo, consistência de hash/tamanho).
- Se a verificação falhar, ele DEVE falhar de forma fechada (fail closed) e tentar novamente o bloco correspondente.
- Para os limites relacionados a falhas de criptografia/autenticação, consulte as seções relevantes do Whitepaper de segurança e privacidade.