Resumo

  • O mestre MTP marcava uma mensagem aceita ao observar data[eom] e todos os pacotes anteriores; incompletude e sua avaliação do produtor levavam a pendente ou rejeitada.
  • Os estados dos últimos doze números viajavam em cada pacote, e um pendente antigo bloqueava novos tokens antes de poder desaparecer da janela.
  • Consumidores bem-sucedidos normalmente ficavam em silêncio, enquanto perdas geravam NAK; aceitação de transporte não era recibo positivo, processamento, autenticação ou resultado operacional.

A confirmação que não existia

RFC 1301 escolheu um protocolo de confirmação negativa. Se um consumidor detectasse falta de dados, enviava NAK. Se tudo parecesse normal dentro das regras do transporte, não mandava um ACK positivo ao produtor. Em multicast, essa economia evitava uma multidão de respostas para cada envio.

O silêncio tinha utilidade operacional, mas não criava documento. Ele dizia que nenhuma lacuna observada acionara recuperação no período pertinente. Não dizia que o aplicativo validara conteúdo, autorizara uma mudança, persistira dados ou entregara algo ao usuário.

Essa é a primeira divisão de evidência. O produtor possui seus envios. Cada consumidor possui suas observações locais. O mestre possui o estado comum. O aplicativo possui significado e efeito. Um único campo não deve responder por todos.

O melhor esforço vinha de baixo

RFC 1112 definia multicast IP como transmissão para um grupo dinâmico. A entrega tinha a mesma confiabilidade de melhor esforço do IP comum: não havia garantia de chegada intacta a todos nem de ordem relativa.

MTP acrescentou organização. Chamou o conjunto de processos de web, exigiu um mestre e distinguiu produtores-consumidores de consumidores puros. O mestre admitia membros, definia parâmetros e distribuía tokens de transmissão. Cada token carregava a autorização protocolar para um produtor usar um número de mensagem.

O endereço de grupo replicava datagramas. O token serializava a fala. O estado de aceitação compartilhava uma conclusão. Nada disso interpretava os dados do cliente, que MTP tratava como octetos opacos.

Aceito era a visão completa do mestre

A regra de decisão era objetiva dentro de um observador definido. Vendo data[eom] e todos os pacotes intermediários, o mestre marcava aceito. Sem a mensagem completa, mas julgando o produtor operacional e conectado, mantinha pendente. Se julgasse o produtor falho ou separado por partição, marcava rejeitado.

Parte da decisão vinha de fatos de recepção; parte vinha de uma avaliação de vivacidade. O vetor final não preservava sozinho a lista de pacotes observados nem o motivo da mudança de julgamento. Para auditoria, é preciso guardar ambos.

O mestre também não conhecia o propósito dos bytes. Uma mensagem aceita podia ser sintaticamente inválida para o aplicativo, duplicada, não autorizada ou sem efeito. Integridade de transporte e resultado de negócio podem divergir sem contradição.

Doze posições continham a dívida

O registro de aceitação levava um indicador de sincronização e doze estados de dois bits. Aceito, pendente e rejeitado descreviam as doze mensagens anteriores. A cada avanço, a janela movia a história e acabava descartando o passado mais antigo.

RFC 1301 proibiu que um pendente fosse simplesmente empurrado para fora. Quando o estado não resolvido chegava à borda, o mestre precisava parar de confirmar novos pedidos de token até escolher aceito ou rejeitado. A incerteza criava contrapressão real.

O mecanismo evitava progresso por amnésia, mas não era arquivo permanente. Decisões finais ainda saíam da janela. Se a organização precisasse provar meses depois por que um estado existiu, teria de registrar externamente o momento, a observação e a autoridade decisora.

Os números de mensagem eram valores de 16 bits iniciados e incrementados pelo mestre. Um número concedido era consumido e exigia término. Era identidade de ordem dentro daquela instância, não identificador imutável de uma operação empresarial.

O token podia chegar duas vezes por causas diferentes

Pacotes de controle não consumiam a sequência normal. Assim, uma nova solicitação de token podia ser inédita ou a repetição de uma solicitação cuja confirmação se perdeu. O produtor podia ter enviado dados invisíveis ao mestre, ou a repetição podia ter ultrapassado uma confirmação atrasada.

O protocolo escolheu uma reação conservadora. Enquanto o token parecesse pendente ao mestre, podia ser reatribuído. Recebendo confirmação duplicada, o produtor a interpretava como NAK e retransmitia os dados ligados ao número. Sem precisar mais do token, enviava empty[cancel].

Essa regra recuperava o fluxo sem declarar qual hipótese era verdadeira. Um log íntegro conserva as duas solicitações, as confirmações, os envios e a observação do mestre em vez de fabricar uma causa única.

Retention encerrava o direito à reparação

heartbeat fornecia o relógio; window limitava novos pacotes e retransmissões por batimento; retention dizia por quantos batimentos o produtor deveria guardar dados para recuperação.

Sem conteúdo suficiente para um pacote cheio, mas antes do fim da mensagem, o produtor enviava empty[dally]. Mensagens curtas eram completadas até pelo menos o número de pacotes indicado por retention. A repetição aumentava a chance de um consumidor observar um pacote e identificar o produtor; não certificava todos os receptores.

Um salto de sequência ou fragmento incompleto seguido de silêncio fazia o consumidor listar faixas faltantes em um NAK unicast. O produtor retransmitia por multicast para todo o web. A recuperação consumia a janela, precedia dados novos e gerava duplicatas para quem não perdera nada. Esses consumidores precisavam descartá-las.

Depois que o dado saía da retenção, nak[deny] informava que a recuperação não era mais possível. O processo receptor relatava falha ao cliente e podia abandonar o grupo. Havia, portanto, diferença entre perda detectada, reparação solicitada, reparação possível, bytes entregues e ação de aplicação.

O identificador de transporte não autenticava o membro

Sobre IP, MTP exigia suporte Level 2 de RFC 1112 e usava 224.0.1.9. Um cabeçalho de ponte adicionava portas, comprimento e checksum opcional sob o protocolo IP 92. TSAP e identificadores distinguiam instâncias.

RFC 1301 dizia que segurança não era discutida. Ser reconhecido pela máquina de estados ou possuir um token não provava identidade humana, controle organizacional ou autorização. A cadeia de segurança precisava ser externa.

A crítica de RFC 1458 separou correção de adequação

RFC 1458 analisou MTP para distribuição de imagens grandes. Reconheceu mestre, tokens, controle de vazão, NAK seletivo e duplicatas. Criticou dependências externas de endereço e identificador e o excesso de controle concentrado no mestre, que criava atraso e congestionamento para aquela carga.

O protocolo podia manter sua semântica e ainda ser inadequado a um cenário. Correção do estado aceito, capacidade do ponto central e utilidade para uma aplicação são três avaliações distintas.

Fontes

As fontes estabelecem especificações e uma revisão histórica, não um web MTP real, população de receptores, membro autenticado, processamento de aplicativo, incidente, adoção ou resultado atual.