Resumo

  • O RFC 3528 permite que o Directory Agent de aceitação devolva SrvAck ao Service Agent antes de encaminhar o registro, de modo assíncrono, aos Directory Agents pares. O recibo fecha a escrita local, não a propagação distribuída.
  • A cadeia completa separa identidade e autorização, accept ID, versão, envio por par, anti-entropia, visibilidade em consultas, vida útil, tombstone, alcance do endpoint, saúde do serviço e resultado da aplicação. Um item no catálogo não comprova todos esses estados.

Um catálogo pode receber uma ficha correta e ainda não cumprir a promessa que o usuário ouviu. O registro já existe em um ponto, mas não aparece em outros; aparece na busca, mas o endereço não responde; responde, mas o usuário não conclui a tarefa.

Publicado em abril de 2003 como protocolo Experimental, o RFC 3528 amplia o SLPv2 com malhas completas por escopo, encaminhamento direto e anti-entropia. Seu mecanismo deixa claro que tornar um registro descobrível é uma sequência, não um único bit.

A inscrição entra por uma porta específica

O Service Agent envia seu estado a um Directory Agent. O DA que aceita a atualização é o accept DA. Quando ele participa do mSLP, passa a distribuir a informação aos pares que compartilham os escopos pertinentes.

Esse segundo ato não precisa anteceder a resposta ao escritor. O encaminhamento direto é assíncrono, e o accept MDA pode devolver SrvAck ao MSA antes de transmitir o Srv(De)Reg a outro MDA.

O recibo prova algo concreto: uma porta reconhecida processou uma carga específica segundo uma decisão local. Não prova que todas as prateleiras da rede já guardam a ficha.

Responder cedo evita que um par lento transforme uma falha de replicação em indisponibilidade de escrita. A arquitetura ganha isolamento. Em troca, telemetria e contratos precisam distinguir “aceito neste DA” de “visível em todo DA relevante”.

O comprovante deve ligar identidade do accept DA, autenticação do MSA, escopos, hash do registro, versão, accept ID, política e resultado. Uma mensagem genérica de sucesso remove justamente o sujeito e o objeto do ato.

Conexão confiável não significa registro instantâneo

Pares mantêm uma conexão persistente, confiável e ordenada para todos os escopos compartilhados. A garantia facilita o transporte contínuo e dispensa um SrvAck para cada atualização recebida de um peer.

Ainda assim, confiável não quer dizer síncrono. Pode haver trabalho pendente antes do envio, interrupção da sessão ou recuperação posterior. A propriedade do canal não comprova que determinado registro já cruzou a fronteira e entrou no índice do outro lado.

Depois da anti-entropia inicial, o accept DA encaminha diretamente as novas atualizações aos pares até ocorrer falha. O salto é único, do ponto de aceitação aos peers relevantes, e não uma inundação recursiva.

Por isso, o recibo de propagação precisa ser por peer: identidade autenticada, escopos comuns, conexão, posição da atualização, resultado do transporte e fronteira observada. Um status “mesh online” pode continuar verde enquanto uma fila específica está atrasada.

Origem, versão e leitura usam relógios diferentes

O accept ID combina a URL do DA de aceitação com um accept timestamp monotônico naquele DA. Atualizações da mesma origem seguem em ordem crescente.

Outro DA possui outra sequência. Atualizações aceitas por origens diferentes podem circular em qualquer ordem relativa. Não existe um relógio total implícito que permita comparar seus números como se viessem do mesmo contador.

O MSA fornece ainda o version timestamp. Ele decide qual versão do mesmo registro é mais recente. O horário de chegada não serve, porque uma versão antiga pode sofrer atraso e chegar depois da nova.

São perguntas separadas: qual conteúdo vence, por qual porta e ordem ele entrou, e o que uma consulta observou. Fundir tudo num único updated_at transforma uma investigação distribuída em adivinhação.

O modelo supõe um SA atualizador por registro. Se uma plataforma permitir múltiplos escritores, deverá criar sua própria política de autoridade e conflito. O RFC não resolve essa concorrência.

Vetores de resumo mostram até onde cada fluxo chegou

Na anti-entropia, um summary vector guarda, para cada accept DA conhecido, o último accept timestamp recebido. O conjunto forma um mapa compacto das fronteiras de vários fluxos.

Um peer pode solicitar estados posteriores a essas marcas. Numa solicitação completa, também entram origens ausentes do pedido. Numa solicitação seletiva, só os accept IDs listados são examinados.

Registrar o modo é indispensável. Uma sincronização seletiva pode terminar com êxito e não dizer nada sobre uma origem omitida. O universo solicitado pertence ao resultado.

Os estados pedidos seguem em ordem de accept ID; ao final do processamento, chega um SrvAck. Esse acuse refere-se à anti-entropia, não ao registro original do Service Agent. O mesmo nome não produz a mesma evidência.

O vetor tampouco certifica saúde. Ele pode estar perfeitamente alinhado para um registro errado, vencido ou cujo endpoint caiu. O mecanismo reconcilia declarações de diretório, não a realidade operacional descrita por elas.

A expiração acompanha o registro

Durante recuperação, a inscrição viaja com a vida útil restante. Não ganha uma nova duração completa. Assim, ciclos de sincronização não rejuvenescem anúncios obsoletos.

Uma desinscrição fica retida como deleted registration. Esse tombstone impede que uma cópia antiga atrasada ressuscite o serviço. Quando o prazo original vence, o estado de exclusão pode ser purgado.

Aceitar a retirada, distribuir o tombstone, deixar de responder em uma consulta e apagar fisicamente são momentos distintos. Uma palavra “deleted” sem origem, observador e hora não distingue nenhum deles.

O recibo precisa conter identidade, versão, accept ID, flag de exclusão, vida restante, caminho de recuperação e amostras de busca. Só assim um registro tardio pode ser classificado como velho, não como reaparecimento legítimo.

Escopo define a superfície de descoberta

Todos os MDAs que servem um escopo formam malha completa. A mesma conexão entre dois peers pode carregar vários escopos em comum. Um MSA só precisa registrar com MDAs cuja união cubra seus próprios escopos, contando com propagação para alcançar os demais.

Logo, aceitação num escopo não fala pelos DAs fora dele. Um User Agent pode escolher outro DA ou consultar sob outro escopo e obter resposta diferente sem contradizer o primeiro recibo.

O RFC escolhe a malha completa por simplicidade e confiabilidade, mas diz que, em geral, ela se destina a dezenas de MDAs ou menos. Trata-se de limite de desenho, não de estatística sobre uma rede atual.

Dividir um escopo pai em dois filhos altera a obrigação. Um serviço antes inscrito apenas no pai pode precisar aparecer em ambos os filhos. Governança de escopo muda o que é encontrável.

A malha replica também um erro de autoridade

O mSLP utiliza a autenticação do SLPv2. Um MDA deve autenticar outros MDAs antes do peering e os MSAs antes de aceitar e encaminhar atualizações; o MSA também deve autenticar o MDA escolhido.

TCP ordenado não prova associação autorizada. Assinatura válida não basta para decidir que a chave pode publicar naquele escopo. Sintaxe correta não confirma que o serviço descrito existe.

Se um MDA for comprometido, todos os outros podem ser afetados pela propagação. A mesma distribuição que melhora descoberta amplia o dano de uma decisão ruim na entrada.

O SLPv2 reconhece que bootstrap sem configuração de segurança prévia pode exigir alguma “fé cega”. Distribuição de chaves e política de confiança continuam sendo trabalho de implantação.

A IANA registra Mesh-enhancement como extensão SLPv2 0x0006, com referência ao RFC 3528. O número evita colisão sem provar suporte, ativação, autenticação, convergência ou disponibilidade.

Ser encontrado ainda não é ser utilizável

O escritor e o leitor percorrem caminhos diferentes. O SA grava num DA; o UA descobre e consulta um DA depois, sob seus próprios escopos.

Uma prova de visibilidade registra o DA consultado, sua identidade, escopos, filtro, hash da resposta, versão, vida restante e horário. Uma promessa de cobertura da malha deve declarar quais observadores foram testados.

Mesmo uma resposta correta é só uma indicação de localização. Ela não estabelece conexão com o endpoint, não executa o protocolo de serviço, não autoriza o usuário e não conclui a ação esperada.

O encadeamento continua por resolução de destino, alcance de rede, handshake, teste de saúde específico e resultado da aplicação. O catálogo ajuda a encontrar; não substitui o objeto encontrado.

Recibos separados, ligados por identificadores

Primeiro, registrar protocolo, status, escopos, identidade do MSA, credenciais, política e autorização. Ligar tudo ao hash, version timestamp, accept DA e accept ID.

Manter o SrvAck inicial como recibo local. Criar eventos posteriores para cada peer, conexão, envio e frontier. Não reescrever o significado do recibo antigo com o conhecimento adquirido depois.

Na recuperação, guardar se a solicitação foi completa ou seletiva, vetor apresentado, origens abrangidas, estados enviados e acuse final. Vida útil e tombstone devem permanecer explícitos.

Consultas e testes do serviço encerram a cadeia. Diretório responde por propagação, segurança por autoridade, dono do serviço por saúde e aplicação pelo resultado. Um painel pode resumir essa cadeia, mas precisa revelar qual elo está verde.

Limite da evidência

Este Artigo não identifica implementação, fornecedor, operador, malha, agente, serviço, endpoint, registro, implantação, incidente, interrupção, ataque ou resultado de cliente. Não mede adoção, tamanho, latência, visibilidade ou saúde atual.

O RFC 3528 é tratado como protocolo Experimental de abril de 2003, não como Internet Standard. Os padrões de 200 segundos para keepalive e 300 segundos para timeout são números do documento, não medições nem configurações reais.

Registros e metadados comprovam identidade documental e valores atribuídos, não comportamento de código em execução.

As notas de Heng Lu sobre autoridade e running code são uma lente editorial declarada. Elas orientam a pergunta sobre os limites do recibo, sem provar intenção do IETF ou conformidade operacional.

A conclusão é estreita: inscrição local, propagação, descoberta, alcance e resultado podem divergir e precisam de provas próprias.

Fontes