Resumo

  • A RFC 3269 tratou o multicast confiável como uma família de projetos dependentes da aplicação, não como um transporte único e universal. Ela transformou a abordagem por blocos em um contrato documental: cada peça reutilizável deveria declarar escopo, interfaces, dependências e limites de falha; uma instanciação do protocolo precisava descrever o sistema completo.
  • O alerta central era composicional: dois componentes podem funcionar em pares e falhar quando combinados. Reutilização era um objetivo de projeto, não uma prova de compatibilidade, segurança, implantação ou adoção.

O problema das fronteiras por trás da modularidade

Reliable Multicast Transport (RMT) partia de uma diferença prática. As aplicações não pediam um único tipo de confiabilidade. Distribuição de arquivos em massa, colaboração interativa e streaming podiam variar em tamanho dos grupos, atraso, ordenação, número de emissores e tolerância a entregas incompletas. A RFC 2357 já tratava essas diferenças e os efeitos externos sobre o congestionamento como motivos para examinar propostas. A RFC 3269 respondia a outra pergunta: se nenhum protocolo serve para todos os casos, o que uma especificação precisa revelar antes que suas peças sejam reutilizadas?

A resposta não era fingir que cada bloco fosse independente. A RFC 3269 reconhecia que alguns dependem do contexto. A junto de B pode funcionar; B junto de C também; A, B e C juntos talvez não. Uma dependência invisível em um par pode virar incompatibilidade quando outro bloco é acrescentado. Uma caixa em um diagrama de arquitetura não prova que a fronteira do componente seja real.

Por isso, o documento de cada bloco deveria justificar a granularidade escolhida, descrever funções e interfaces externas, casos de uso, falhas conhecidas e como detectá-las, ambientes e incompatibilidades, além de questões pertinentes de segurança e de códigos. Quando aplicável, os campos de pacotes e as exigências dirigidas a outros blocos também precisavam ficar explícitos. Assim, o próximo projetista poderia avaliar se a peça servia a um novo cenário, sem inferir portabilidade pelo nome.

Um componente não é o protocolo montado

A RFC 3269 traçou outra fronteira para a instanciação de protocolo: o documento que combina blocos e forma um protocolo completo. Ele precisava definir aplicação e escala, ambientes incluídos e excluídos, fragilidades conhecidas, arquitetura, componentes escolhidos, como se conectavam e quais escolhas envolviam compromissos. Também deveria especificar algoritmos e formatos de pacotes completos, em vez de deixar a implementação adivinhar detalhes ausentes da descrição abstrata de um bloco.

A declaração de conformidade deixou claro qual era a unidade da afirmação: a instanciação, junto dos documentos dos blocos citados, deveria especificar por completo um protocolo RMT funcional, conforme os requisitos anteriores da RFC 2357. Isso não transformou a RFC 3269 em relatório de testes nem garantiu interoperabilidade entre implementações. O que ela definiu foi a documentação que o leitor deveria conseguir examinar antes de avaliar a expressão “protocolo funcional”.

Uma regra sobre formatos de pacotes mostra bem essa fronteira. A instanciação RMT inicialmente precisava definir uso sobre UDP; a decisão de pedir um número de protocolo IP próprio ficava adiada até que o protocolo estivesse suficientemente implantado e compreendido. Assim, o texto separava projeto completo, alocação de um identificador escasso no registro e evidência de adoção posterior. A regra é um limite documental, não prova de implantação ampla de um protocolo específico.

A RFC 3048 descrevia a separação entre blocos reutilizáveis e núcleos próprios de cada protocolo. A RFC 3269 acrescentou obrigações para que os autores tornassem essa separação legível. Em 2009, a RFC 5651 afirmou explicitamente que seguia suas diretrizes ao atualizar a especificação anterior do bloco LCT: um exemplo rastreável de continuidade documental. A citação mostra uma linhagem de método, não conformidade universal nem resultado de implantação.

A conclusão histórica é mais restrita — e mais útil — do que “a modularidade vence”. A RFC 3269 condicionou a reutilização à divulgação do escopo e fez da completude uma propriedade do protocolo montado, não de cada componente isolado. Ela podia melhorar o que os autores expunham à análise. Não podia fazer especificações separadas comporem com segurança apenas por declaração.

Fontes