Resumo

  • A RFC 3384 exigia que réplicas multimestre chegassem ao mesmo estado vivo, mas também que a informação deslocada pela resolução de conflito fosse guardada, comunicada ao administrador e passível de revisão.
  • A ordem em que atualizações atravessavam a rede não podia escolher o vencedor. Convergência e preservação da discordância eram obrigações diferentes.

Uma atualização foi aceita no mestre do escritório leste. Outra, incompatível, foi aceita no mestre oeste durante a mesma interrupção. Quando a comunicação voltou, havia duas histórias localmente válidas e uma única pergunta para os leitores: qual valor está em vigor? A replicação precisava responder. O que ela não podia fazer, segundo a RFC 3384, era responder destruindo a única prova de que a alternativa existira.

Publicada em outubro de 2002 como Informational, a RFC reunia requisitos fundamentais para replicação interoperável de diretórios LDAPv3. Não era um protocolo completo, um padrão de implementação fechado nem evidência de adoção por produtos específicos. Seu valor histórico está em declarar propriedades que qualquer solução aceitável teria de demonstrar, deixando os mecanismos concretos para trabalhos posteriores.

LDAP já definia a comunicação entre clientes e servidores. A replicação servidor a servidor acrescentava disponibilidade e proximidade, mas também introduzia topologias, cópias parciais, esquemas divergentes, controle de acesso, repetição de mensagens e escritas concorrentes. O problema não era apenas mover bytes; era manter significado e responsabilidade enquanto diferentes cópias mudavam.

O documento chamava de área de replicação uma parte configurável da Directory Information Tree. Áreas podiam se sobrepor ou ficar aninhadas. Uma réplica era uma instância dessa área, e o grupo de réplicas reunia os servidores que a continham. O acordo de replicação definia área, acesso, credenciais, confidencialidade e propagação. Assim, a frase “está sincronizado” sempre depende de qual escopo e qual acordo estão sendo medidos.

Cinco modelos de consistência foram considerados. A consistência transacional prometia propriedades ACID, mas o commit distribuído em duas fases trazia complexidade suficiente para não ser perseguido naquele momento. As exigências se concentraram em consistência eventual e consistência eventual de esforço limitado. Divergir durante uma partição era possível; permanecer sem um caminho de reconciliação, não.

M3 exigia que um atributo convergisse para o mesmo conjunto de valores em toda réplica que mantivesse a entrada. MM6 reafirmava a convergência de atributos e entradas em ambientes multimestre. A indisponibilidade podia adiar o consenso operacional, porém não transformava a igualdade final em opção.

O conflito era consequência prevista da própria disponibilidade. Vários mestres podiam receber escritas sem consultar os demais primeiro. Duas mudanças podiam atingir a mesma informação antes que uma enxergasse a outra. Na reunião das cópias, um mecanismo determinístico precisava decidir o estado vivo.

Determinismo não podia significar “vence o último a chegar”. Réplicas distintas podem receber o mesmo conjunto de mudanças em ordens opostas. Se cada uma concede autoridade à sua última entrega, elas escolhem vencedores diferentes. MM7 determinava que a resolução não dependesse de chegada ordenada para assegurar convergência. O percurso dos pacotes não era fonte legítima de autoridade permanente.

A RFC 3384 não escolheu um relógio lógico, uma prioridade de servidor nem uma comparação universal de carimbos de tempo. Fixou uma propriedade mais básica: dentro do modelo suportado, observadores independentes precisavam conseguir o mesmo resultado apesar de sequências de entrega diferentes. Essa formulação preservava escolha técnica sem tolerar correção baseada em acaso de rede.

MM5 acrescentava o limite decisivo. A replicação multimestre não deveria perder informação. Quando resolver o conflito retirasse informação do diretório convergido, o processo precisava armazená-la, avisar o administrador sobre conflito e perda e oferecer um meio para possível intervenção administrativa.

Isso não significava manter os dois valores incompatíveis como atuais. Fazer isso apenas transferiria a decisão para cada cliente. A exigência separava o estado vivo, único e utilizável, de um plano de evidência com o que a regra automática deslocou. O administrador poderia examinar a alternativa e substituir o vencedor se a evidência justificasse.

Por isso, réplicas idênticas não bastam para provar integridade. A igualdade mostra qual valor está visível agora. Não mostra se o vencedor era correto, se o perdedor continua recuperável ou se alguém foi notificado. Um painel totalmente verde pode descrever propagação bem-sucedida e, ao mesmo tempo, esconder governança deficiente.

M12 tratava a repetição. Receber a mesma atualização mais de uma vez não poderia produzir resultado diferente de recebê-la uma vez. Uma conexão pode cair depois da aplicação e antes da confirmação. O fornecedor reenvia porque não sabe o que ocorreu. Se a repetição contar como nova mutação, o mecanismo de recuperação causa corrupção.

P6 preservava a atomicidade prometida pelas operações LDAP. As partes de uma única operação não deveriam aparecer separadamente por causa do transporte. Ainda assim, duas operações completas e atômicas podiam entrar em conflito. Atomicidade impedia uma escrita rasgada; não decidia entre duas intenções inteiras.

Conflitos de início de sessão tinham outra natureza. Se vários mestres tentassem começar um ciclo com a mesma réplica, MM4 exigia solução ou prevenção automática. Consumidor ocupado, conexão perdida e reagendamento pertenciam à coordenação da sessão. Discordância entre valores pertenciam à reconciliação de dados. Chamar ambos apenas de “conflito” apagaria ações diferentes.

Administrar fazia parte da interoperabilidade. AM2 exigia que cada réplica mantivesse histórico dos servidores com os quais replicara. AM4 e AM5 pediam comparação e reparo de diferenças sem iniciar novos ciclos. Uma réplica vazia precisava ser inicializável por atualização completa. A reconciliação deveria deixar rastros e controles visíveis.

Embora a ordem geral de chegada não pudesse eleger o vencedor, algumas relações causais precisavam ser preservadas. AM6 exigia sequência entre informação de controle de acesso e os dados que ela governava. Receber o dado antes da política protetora poderia criar temporariamente outro significado de segurança. Ordem acidental e dependência explícita eram coisas distintas.

Incompatibilidades de esquema tinham de ser tratadas e reportadas. A replicação abrangia definições, nomes e valores de atributos, controle de acesso, conhecimento e namespace. Excluía como tais atributos operacionais específicos do DSA. Réplicas parciais eram possíveis, mas o acordo precisava tornar explícitos área, entradas e atributos presentes.

Autenticação, autorização, integridade e confidencialidade continuavam separadas. As sessões deveriam suportar autenticação mútua, verificação mútua de autorização e transporte protegido. O texto também exigia suporte a sessões anônimas. Isso não igualava a confiança; exigia representar regimes e consequências políticas diferentes.

As especificações posteriores ajudam a montar a cronologia, mas não certificam implementação integral. As RFCs 4510, 4511 e 4512 reorganizaram a especificação LDAP. A RFC 4533 definiu sincronização de conteúdo, e a RFC 5805, transações. Proximidade temática não demonstra que todas as exigências multimestre da RFC 3384 foram atendidas por esses mecanismos ou por qualquer produto nomeado.

A RFC 3383, publicada pouco antes, mostra outra superfície de coordenação. Ela organizava políticas para registrar identificadores de extensões LDAP e reduzir colisões no namespace. A RFC 3384 perguntava o que fazer quando mudanças legítimas colidiam no tempo entre cópias. Uma regulava a entrada de nomes; a outra preservava evidência de disputa sobre estado.

A lente de especificação inicial mínima de Lu Heng explica por que requisitos sem algoritmo único ainda exercem controle. A especificação podia proibir autoridade baseada em chegada, perda silenciosa e ausência de recurso, sem impedir que implementações futuras escolhessem métodos locais. Deixar o mecanismo aberto não significava deixar o dano sem limite.

Já a lente das camadas de realidade separa fatos que um painel tende a fundir: escrita aceita, atualização transportada, conflito detectado, vencedor exposto, perdedor armazenado, administrador alertado e revisão concluída. “Convergente” descreve apenas parte dessa cadeia. Usá-lo como sinônimo de decisão correta transforma medição técnica em alegação de governança.

A lição duradoura é desconfiar de uma convergência limpa demais. Um sistema distribuído pode obter uma resposta única eliminando a história que permitiria contestá-la. Ao preservar o valor perdedor, a RFC 3384 transformou sobrescrita silenciosa em decisão auditável. As réplicas podiam concordar sem fingir que nunca discordaram.

Fontes