Resumo

  • A RFC 2443 permitiu que vários servidores de resolução multicast sobre ATM compartilhassem o estado dos clientes e dos grupos, mantendo cada cliente registrado em apenas um servidor.
  • Depois de duas atualizações de presença consecutivas não recebidas, os pares tinham de descartar as associações aprendidas daquele servidor. O cliente, então, precisava se registrar em um servidor reserva e entrar novamente nos grupos.

Três caches concordam; a origem, porém, silenciou

Imagine três servidores MARS exibindo a mesma associação: um cliente participa de um grupo multicast. A visão compartilhada parece íntegra. Então o servidor que registrou aquele cliente para de enviar sua atualização periódica de redirecionamento. Os outros dois ainda possuem registros idênticos, mas a RFC 2443 não trata essa concordância como prova de que a origem — ou o cliente ligado a ela — continua ativa. Depois de duas atualizações consecutivas ausentes, eles devem remover as associações aprendidas daquele servidor.

Essa distinção orientava o projeto. A RFC 2022 descrevera o MARS, servidor de resolução de endereços multicast, como meio de distribuir informações de conexão e associação da camada 3 em redes ATM. Em um serviço MARS distribuído, cada servidor de uma Sub-rede IP Lógica (LIS) precisava responder sobre qualquer grupo daquela sub-rede. Publicada como RFC Experimental em novembro de 1998, a RFC 2443 adaptou o Server Cache Synchronization Protocol (SCSP) para replicar esses registros entre servidores MARS.

Replicavam-se os registros, não a titularidade da relação

O SCSP fornecia uma estrutura de sincronização: os servidores estabeleciam uma relação, alinhavam os caches e depois propagavam as mudanças. A RFC 2443 reservou o identificador de protocolo 0x0003 para o MARS e delimitou o grupo de servidores pela LIS. Quando um cliente se registrava em um servidor, este propagava o registro e as mudanças posteriores de grupo aos pares. Ainda assim, cada cliente se registrava em apenas um MARS e se conectava pelo circuito virtual de controle de cluster ou pelo circuito virtual de controle de servidor desse MARS. As cópias ampliavam o que o grupo podia consultar; não duplicavam a relação de controle do cliente em vários servidores.

A replicação tampouco resolvia quem podia atribuir os identificadores. Cada cliente MARS precisava de um Cluster Member ID exclusivo em toda a LIS. A RFC pressupunha que cada servidor tivesse uma faixa distinta; uma alocação externa era possível, mas ficava fora do escopo. Sincronizar bases pode reproduzir com precisão um identificador em conflito. Isso não cria, por si só, uma autoridade que assegure a unicidade.

O heartbeat servia para invalidar conhecimento antigo

Cada servidor tinha de atualizar sua MARS Server Redirect Entry pelo menos a cada dois minutos; a recomendação era fazê-lo a cada minuto. Se um par deixasse de receber duas atualizações consecutivas de uma origem, deveria remover todas as informações de clientes e grupos aprendidas dela. A regra não servia apenas para renovar uma lista de servidores reserva. Ela vinculava a validade da informação a uma origem específica e limitava a remoção ao estado dependente daquela fonte.

A recuperação voltava a depender do cliente. Ao detectar a falha de seu MARS, ele escolhia um servidor reserva e tentava se registrar. Só depois de um registro bem-sucedido voltava a participar dos grupos anteriores. Se falhasse, tentava outro servidor. O mapa de redirecionamento indicava destinos possíveis; não comprovava que aquele cliente já havia migrado, se registrado novamente, recuperado suas associações ou voltado a receber multicast.

Uma linha de associação restaurada tampouco prova que um circuito ATM ponto a multiponto foi reconstruído ou que pacotes chegaram à aplicação. São etapas operacionais diferentes. Em redes em funcionamento, uma linha replicada do plano de controle é uma entrada para uma ação, não o recibo de sua conclusão.

A autenticação limitava a entrada, mas ampliava o raio de confiança

A RFC 2443 não criptografava os campos específicos do MARS nos registros de estado. Ela apontava para os recursos de segurança da parte genérica do SCSP. A autenticação podia fazer com que pacotes não autenticados fossem descartados, mas a RFC também era explícita: o estado recebido de qualquer servidor autenticado corretamente era confiado e propagado pelo grupo. Se um servidor autenticado fosse comprometido, a base compartilhada poderia ser corrompida a partir dele. A autenticação restringia quem podia falar; não tornava verdadeiras as informações enviadas nem continha os danos de um par comprometido.

Em 2004, a RFC 3790 observou que a RFC 2443 definia valores padrão para IPv4 e permitia extensão a IPv6 com definições IANA adequadas. Isso documenta uma intenção de projeto, não uma prova de implementação ou adoção. As RFCs registram requisitos e alertas, mas não demonstram a frequência de uso nem o comportamento de todas as implementações.

A lição duradoura vai além de “replicação melhora disponibilidade”. É preciso saber quem originou cada registro, quando a origem foi vista pela última vez, o que deve ser invalidado quando essa evidência expira e quem executa a próxima etapa. Depois, meça separadamente registro, retorno aos grupos, reconstrução do circuito, encaminhamento de pacotes e recebimento pela aplicação. Três caches podem concordar sobre o passado. Só um cliente ativo e um caminho de dados funcional mostram que o multicast voltou.

Fontes