Summary

  • O rascunho CoRE pubsub, revisão 22, atualizado em 2 de novembro de 2026, propõe um broker para clientes CoAP que passam longos períodos desconectados. Publicadores enviam PUT; assinantes observam o recurso de dados ou fazem GET da última representação. O documento ainda está sob avaliação da IESG.
  • A seção 3.3 só define a busca do dado mais recente. A leitura de representações antigas e a quantidade guardada pelo broker ficam para uma especificação futura.
  • Um tema existente, uma publicação aceita e uma assinatura confirmada são resultados distintos. Se a resposta não traz a opção Observe, a assinatura não aconteceu, mesmo quando o código da resposta indica êxito.

Imagine uma sonda de temperatura que registra um pico enquanto o console de manutenção está sem conexão. Mais tarde publica uma leitura normal. Quando o console volta, o broker lhe entrega a leitura mais recente. A equipe enxerga o último dado recebido pelo broker e pode perder o episódio inteiro caso não possua outro registro. É um cenário para testar o alcance do texto, não uma ocorrência industrial narrada pelos autores.

O projeto do grupo CoRE põe o broker entre dispositivos que não precisam estar ativos ao mesmo tempo. Ele hospeda coleções de temas, recursos de configuração e recursos separados de dados. O publicador usa PUT na URI do dado. O assinante faz GET com Observe: 0, de acordo com o RFC 7641, para receber atualizações. Um GET simples recupera o dado corrente. A URI da configuração não precisa se parecer com a URI dos dados; esta é descoberta na propriedade topic-data.

O valor atual tem limites muito claros

Criar um tema cria também seu recurso de dados, ainda vazio. O rascunho usa a resposta proposta 2.06 No Content quando esse recurso existe mas ninguém publicou uma representação. Se o recurso não existe, a resposta típica é 4.04 Not Found. Se existe conteúdo, o broker devolve a última publicação. Essas respostas contam histórias diferentes. Reduzi-las todas a um painel “sem ocorrência” destrói a primeira pista da investigação.

O próprio texto afirma que sua leitura cobre apenas a última representação. Consultar valores anteriores e configurar quantos devem ficar armazenados são possibilidades para trabalho posterior. Portanto, o fato de o broker ter recebido um alarme e depois um valor normal não cria automaticamente uma função de replay. Se o operador precisa apurar duração, ordem e destinatários de um evento, deve manter uma trilha histórica durável fora desse contrato de leitura.

A assinatura contínua também pede leitura rigorosa. Um GET com Observe: 0 pode receber 2.05 Content com a opção Observe e os dados atuais. Se o tema ainda está vazio, pode receber 2.06 No Content com Observe e esperar a primeira publicação como notificação. A ausência da opção informa falha na assinatura, independentemente de o código ser 2.05 ou 2.06. Quando max-subscribers foi atingido, o broker não inclui Observe. Um software que confunde qualquer resposta de sucesso com vigilância ativa pode ficar fora do circuito sem perceber.

Os temas também terminam. Sua exclusão remove o recurso administrativo e o recurso de dados; observadores recebem um 4.04 final. Uma data de expiração opcional pode acionar a exclusão. Um intervalo sem mensagens pode significar cliente desligado, assinatura recusada, tema vazio ou tema removido. Cada hipótese exige um registro diferente.

Receber o PUT não é entregar o aviso

Na publicação, o retorno usual 2.04 Changed segue o modelo de requisição e resposta CoAP do RFC 7252. Ele comprova que o broker aceitou a mudança, não que todos os assinantes a receberam ou que a aplicação agiu. Se os envios chegarem rápido demais, o broker pode responder 4.29 Too Many Requests; Max-Age define quando o publicador pode tentar de novo. Para reconstruir uma falha, importam tanto publicações aceitas quanto recusadas.

O texto exige proteção da comunicação entre cada cliente e o broker. Também recomenda proteção do conteúdo de ponta a ponta com autenticação da origem, para o assinante verificar quem publicou. Uma conexão segura até o broker não autentica por si a sonda diante do destinatário. Depois da autenticidade ainda vêm entrega, interpretação e ação.

O serviço proposto tem valor para sensores que dormem: reencontrar o estado mais recente sem exigir presença constante. O rascunho não apresenta medições de implantação nem promete conservar toda mudança intermediária. O dado que alteraria a decisão operacional é uma linha do tempo com publicações aceitas, entregas e respostas da aplicação durante a desconexão. Sem essa linha, a leitura normal responde à pergunta sobre agora e silencia sobre a hora anterior.

Rascunho CoRE pubsub · RFC 7641 · RFC 7252