Resumo

  • A RFC 3082 permite que um agente de usuário assine mudanças nos serviços em vez de consultar a rede continuamente; a presença de Directory Agents define qual caminho de notificação será usado.
  • Se um DA desaparecer, agentes de serviço já avisados podem continuar enviando mensagens, mas um agente novo pode não receber a assinatura. A continuidade dos avisos antigos não prova que os serviços novos estejam cobertos.

Consulta não é fluxo de eventos

O Service Location Protocol partiu de uma lógica sob demanda: agentes de serviço (SAs) anunciavam serviços e agentes de usuário (UAs) os consultavam quando precisavam. Uma aplicação que quisesse atualizar sua visão sempre que um serviço surgisse ou desaparecesse precisava consultar a rede periodicamente. Publicada em março de 2001 como protocolo Experimental, a RFC 3082 propôs avisos de mudança para evitar essas consultas repetidas. Ela não é um Internet Standard.

Trocar consulta por assinatura parece simples até aparecer a pergunta sobre o próximo agente: quem lhe informa que um UA está escutando? A resposta depende da existência de Directory Agents (DAs). As duas topologias não guardam a mesma informação no mesmo ponto.

Duas topologias, dois custos

Em redes pequenas sem DA, os SAs anunciam registros e cancelamentos por multicast IP — ou broadcast IPv4 quando o multicast não está disponível. Os UAs recebem avisos de vários tipos e escopos e filtram localmente. Assim, nenhum intermediário precisa contar a cada SA novo quem assinou; em compensação, os ouvintes processam mensagens irrelevantes e o alcance do multicast precisa ser administrado.

Em redes maiores com DA, o UA acrescenta a extensão Subscribe a uma requisição de serviço. O DA devolve grupos multicast NotifyAt para os tipos e escopos pedidos. Pode avisar os SAs existentes por meio de um DAAdvert e incluir a mesma instrução no SrvAck de um novo SA correspondente. Se uma publicidade expirar sem cancelamento ordenado, o próprio DA também envia um aviso de cancelamento. Os SAs continuam sendo os principais emissores das mudanças; o DA não retransmite centralmente cada evento.

O trabalho fica distribuído, mas o estado também. O DA guarda assinaturas; os SAs já informados guardam os endereços dos grupos; o UA entra neles; e a alocação e o prazo do endereço multicast constituem outro estado. Para evitar que vários DAs anunciem o mesmo NotifyAt, cada um espera um intervalo aleatório uniforme de zero a três segundos e escuta anúncios coincidentes dos demais. Isso reduz duplicatas. Não replica a tabela de assinaturas nem cria uma base compartilhada durável.

O que desaparece — e o que continua

A seção 10 descreve uma falha parcial. Quando um DA some de forma inesperada, perde-se a informação sobre as assinaturas dos UAs que ele guardava. Mesmo assim, os UAs continuam recebendo avisos dos SAs existentes, que já conheciam o NotifyAt. Um SA novo não recebe essa informação, a menos que outro DA também mantenha a assinatura.

O UA talvez só descubra um DA alternativo ao fazer uma requisição ativa. Um serviço, então, pode se registrar depois da perda do DA antigo e antes que o UA encontre outro e renove a assinatura. O fluxo parece ativo porque os serviços antigos continuam aparecendo; o recém-chegado pode nunca aparecer.

A recuperação prevista protege os emissores conhecidos. Eles notificam até o vencimento da assinatura; se não houver outro DA disponível, ignoram esse vencimento e continuam até descobrirem um novo. Depois de se registrar nele, o SrvAck informa ao SA se o UA renovou. Mas a própria RFC reconhece uma janela residual: SAs que iniciam entre a volta do DA e a renovação pelo UA ainda podem não ser avisados. Para receber notícia de absolutamente cada serviço, o UA deve assinar com cada novo DA que atenda aos seus escopos. Ter várias caixas não replica, por si só, o estado da assinatura.

Um aviso não prova que o serviço foi concluído

O restante do mecanismo reforça a separação entre evidências. As notificações multicast são repetidas por quinze segundos, com intervalos que aumentam exponencialmente. A RFC diz que isso eleva a probabilidade de uma mensagem chegar — não garante entrega nem cria um log persistente que possa ser reexecutado. Uma lista de atributos pode exceder o MTU de UDP; o bit de overflow informa que talvez seja preciso consultar depois o SA ou o DA.

A RFC também descreve blocos de autenticação que o UA pode verificar, mas autenticar a mensagem não prova que todos os ouvintes a receberam, que o endpoint continua alcançável ou que a aplicação completou sua operação.

É preciso separar a assinatura do UA, o estado de tipo e escopo no DA, o NotifyAt recebido pelo SA, a participação no grupo multicast, o envio do evento, sua recepção, uma consulta posterior quando faltam atributos e o intercâmbio final com o serviço. A RFC define algumas transições; não as transforma em um único comprovante de ponta a ponta.

As duas partes do título são compatíveis. A RFC 3082 não diz que a falha de um DA interrompe todos os avisos: SAs existentes podem continuar e outros DAs podem preservar cobertura. O ponto é mais específico: a continuidade de quem já foi informado não equivale à cobertura de quem chega depois. Substituir polling por notificações muda onde a rede precisa lembrar quem está ouvindo — e qual etapa de recuperação deve restaurar essa memória.

Fontes

Texto e histórico: RFC 3082, registro do RFC Editor, histórico no Datatracker, RFC 2608: SLPv2, RFC 2119, RFC 2373, RFC 2730 e RFC 2908. Referências editoriais, não evidência do comportamento de SLP: Lu Heng, Running-Code Primacy e On Reality Layers.