Summary

  • A revisão 17 do rascunho CoAP Observe multicast, de 2 de novembro de 2026, propõe uma notificação para vários clientes que observam o mesmo recurso. Continua sendo um Internet-Draft.
  • A opção Feedback-Divider sorteia quais clientes interessados responderão. Cada um tem probabilidade 1 / 2^Q de responder; o servidor recebe R confirmações e calcula E = R × 2^Q.
  • No exemplo do rascunho, a estimativa inicial é 32, mas há 18 observadores ativos. Cinco decidem responder, uma resposta se perde e quatro chegam. O indicador vira 16 e, com o amortecedor do exemplo, a nova estimativa também é 16.

Pense em sensores que acompanham o estado de um mesmo recurso. Pelo RFC 7641, cada cliente CoAP pode se registrar para receber mudanças. Mandar uma resposta separada a cada sensor custa mais a cada novo inscrito. O novo rascunho permite reunir esses clientes numa observação de grupo e enviar uma só notificação multicast. O ganho em envio é direto. A pergunta sobre quantos clientes ainda querem receber deixa de ter resposta direta.

O servidor cria internamente uma solicitação Observe «fantasma», que representa o grupo, e usa um Token compartilhado. Nenhum dispositivo imaginário transmite essa solicitação. Os clientes recebem os parâmetros da observação e escutam as notificações. O servidor sabe quando emitiu uma mensagem; não obtém daí uma lista de quem a recebeu. Por isso conserva um contador que o documento chama de estimativa aproximada dos observadores ativos e interessados.

O retorno vem de uma amostra

Na seção 8 da revisão 17, o servidor coloca Feedback-Divider com valor Q numa notificação. Cada cliente compatível que deseja continuar escutando sorteia um inteiro entre zero e 2^Q, sem incluir o limite superior. Só quem tira zero envia uma nova inscrição Observe unicast, depois de uma espera aleatória. Os demais podem estar ativos e permanecer calados. O sorteio evita que a resposta de todos recrie o congestionamento que o multicast pretendia reduzir.

O servidor conta as confirmações válidas recebidas, R, e multiplica por 2^Q para obter o indicador E. Se a chance de resposta é de um quarto, quatro respostas sugerem dezesseis interessados. Não são dezesseis recibos individuais. A amostra varia e alguns pacotes de retorno desaparecem. O rascunho reconhece que a perda de pacotes distorce a estimativa. O servidor compra economia de envio com incerteza sobre o tamanho da plateia.

Há clientes novos chegando durante a contagem. O rascunho parte do contador corrente COUNT', compara E com a estimativa anterior N e ajusta o valor por (E − N) / D, com D inteiro positivo que amortece a mudança. A atualização deve ser atômica em relação a novas inscrições; uma correção do número antigo não pode apagar quem acabou de entrar. Essa regra protege o cadastro interno. Ainda não diz se uma notificação específica chegou a cada aparelho.

O exemplo numérico expõe a diferença. O servidor estima 32 clientes e escolhe Q=2, oferecendo a cada um uma chance em quatro de responder. Na narrativa há 18 ativos; cinco são sorteados e uma resposta se perde. As quatro que chegam dão E=16. Com D=1, o contador passa de 32 para 16 e a observação de grupo permanece. O número real 18 foi fornecido pelos autores para explicar o método. Um servidor em operação enxergaria apenas as respostas recebidas e suas hipóteses.

Poupar pacotes transfere uma escolha ao operador

Com Q=0, todos os clientes ativos são convidados a confirmar. O tráfego de retorno cresce e perdas ainda podem ocorrer. Perguntar com menor frequência poupa mais rede, mas deixa a estimativa envelhecer. Um amortecedor maior reage mais devagar. Cabe à aplicação decidir quando consultar de novo e quando cancelar a observação de grupo. Encerrar cedo pode deixar interessados sem a atualização compartilhada; manter um grupo vazio consome recursos. O protocolo oferece um contador, e a operação escolhe como usá-lo.

O RFC 7252 define a base das mensagens CoAP. A proposta de multicast muda o custo de distribuir atualizações Observe. Seu contador estima interesse, não recebimento, processamento ou ação. Uma tela de temperatura pode tolerar um público aproximado ao escolher o meio de envio. Uma instrução destinada a um aparelho específico precisa de resposta daquele aparelho.

Os registros oficiais não medem uma implantação nem a distribuição real de perdas. Um teste controlado, com número conhecido de clientes, respostas sorteadas, pacotes perdidos e notificações entregues, mostraria o erro do contador antes de definir limites de cancelamento. A troca é clara: um aviso para todos reduz o custo; descobrir quantos ainda estão ali vira sorteio.

Rascunho CoAP Observe multicast · Registro Datatracker · RFC 7641 · RFC 7252