Resumo

  • O MARS mantinha o mapeamento entre o grupo de camada 3 e os terminais ATM do cluster, mas a própria RFC dizia que ele não participava do multicast de dados.
  • Um emissor, mesmo não sendo membro, precisava completar a sequência MARS_MULTI e criar seu VC, ou usar o endereço de um MCS que escondia a redistribuição seguinte.
  • Cadastro, resposta completa, folha anexada, CSN contínuo e chamada de envio comprovavam etapas diferentes; nenhum deles isoladamente provava disponibilidade, entrega, identidade, autorização, QoS ou segurança.

A arquitetura da RFC 2022 começa com uma recusa: o servidor de resolução não é o encaminhador. MARS registrava associações entre endereços multicast IP e endereços ATM, respondia consultas e anunciava mudanças. Os dados percorriam conexões montadas pelos terminais.

Isso era necessário porque um grupo IP não era diretamente uma chamada ATM. O emissor consultava o mapa atual, solicitava a criação de um VC ponto a multiponto e acrescentava cada endereço retornado como folha. Segundo a RFC 1112, ele nem sequer precisava integrar o grupo para enviar. A consulta, portanto, não era prova de filiação.

A lista só existia quando a última parte chegava

Respostas grandes podiam ser repartidas em vários MARS_MULTI. O bit x marcava o encerramento e y ordenava as partes. Um intervalo, uma expiração ou uma sequência incompatível invalidava o conjunto parcial. Apenas a resposta terminada formava o instantâneo que a sinalização poderia usar.

Mesmo completo, o instantâneo não garantia alcançabilidade. A inclusão de folhas ocorria depois e podia falhar individualmente. A RFC permitia tentativas posteriores e o começo da transmissão enquanto ainda havia folhas pendentes. Um VC ativo não significava que todos os destinatários já estavam conectados; entregar bytes à pilha local não significava que as aplicações os receberam.

O endereço do MCS era uma entrega intermediária

Em clusters com Multicast Server, o MARS podia devolver apenas o endereço do MCS. Para o emissor, uma folha de servidor parecia uma folha comum. Na prática, o MCS recebia os pacotes e fazia o novo leque de envios.

O desenho simplificava o terminal, mas ocultava a etapa final. O endereço retornado não descrevia os membros atrás do servidor nem comprovava a redistribuição. A RFC 2149 estudou depois as arquiteturas e a coordenação entre vários MCS; essa evolução não pode ser tratada como garantia retroativa da RFC 2022.

Mudanças de grupo corrigiam cópias locais

Os membros recebiam MARS_JOIN e MARS_LEAVE pelo ClusterControlVC. Cada emissor aplicava os avisos aos seus VCs. A saída da última folha fechava o circuito; o pacote seguinte reiniciava consulta e construção.

O Cluster Sequence Number denunciava uma possível lacuna no fluxo de controle. MARS incrementava o número em toda transmissão, mesmo sem mudança no cadastro. Por isso, um salto não identificava o evento perdido: apenas obrigava a revalidar todos os VCs abertos consultando novos mapas. O tráfego podia prosseguir durante a conferência.

Continuidade do CSN era prova de uma sequência observada, não de sucesso de sinalização, vida do receptor ou entrega.

O escopo impedia conclusões maiores

A RFC 2022 limitou-se a um MARS Cluster. Roteamento entre clusters e conversão de QoS de camada 3 em parâmetros ATM ficaram fora. Coordenação de MARS de reserva, remoção de membros mortos e múltiplos MCS não receberam solução completa. Segurança não foi discutida.

Consequentemente, cada registro deve permanecer estreito. Filiação, lista completa, folha, MCS, sequência e envio não se somam automaticamente a presença, recebimento, identidade ou autorização. São recibos de ações e estados diferentes.

O legado da RFC 2022 é mostrar que um diretório pode orientar um caminho sem ser o caminho. A rede funcionava porque os terminais reconciliavam repetidamente as duas coisas, não porque o cadastro tivesse virado uma verdade permanente sobre entrega.

Fontes