Summary

  • El borrador de Observe multidifusión para CoAP, revisión 17, fechado el 2 de noviembre de 2026, permite enviar una notificación a un grupo que observa el mismo recurso. Sigue siendo un Internet-Draft.
  • La opción Feedback-Divider solicita confirmación a clientes elegidos al azar. Cada interesado responde con probabilidad 1 / 2^Q; el servidor recibe R respuestas y calcula E = R × 2^Q.
  • En el ejemplo del borrador, el servidor espera 32 observadores y hay 18 activos. Cinco deciden responder, una respuesta se pierde y cuatro llegan. El indicador es 16 y, con el amortiguador del ejemplo, la cuenta estimada pasa a 16.

Un servidor publica el cambio de una variable que vigilan decenas de aparatos. Con CoAP Observe, RFC 7641, cada cliente puede inscribirse para recibir novedades. Mandar una respuesta individual a cada uno hace que la carga crezca con la audiencia. El borrador propone agruparlos y enviar una sola notificación multidifusión. Se ahorra trabajo por cada actualización. A cambio, la lista de receptores deja de estar delante del servidor.

Para representar al grupo, el servidor procesa localmente una petición Observe «fantasma» y comparte un Token entre quienes participan. Ningún aparato imaginario transmite esa petición. Los clientes conocen los parámetros del grupo y se preparan para recibir sus mensajes. El servidor sabe que emitió una notificación; esa emisión no le dice cuántos clientes siguen interesados ni cuáles recibieron cada paquete. Por eso conserva un contador que el texto llama estimación aproximada de observadores activos.

La respuesta llega de una muestra

La sección 8 de la revisión 17 evita que todos los clientes contesten al mismo tiempo. El servidor incluye Feedback-Divider con valor Q. Cada cliente compatible que desea seguir escuchando elige un entero aleatorio entre cero y 2^Q, sin incluir ese límite. Solo si obtiene cero envía una nueva solicitud Observe unicast, después de una espera aleatoria. Quien no sale elegido guarda silencio aunque continúe activo.

El servidor cuenta las confirmaciones válidas que llegan, R, y las multiplica por 2^Q para obtener el indicador E. Si se invitó a una cuarta parte y llegaron cuatro respuestas, la cifra sugerida es dieciséis. No es un censo: el sorteo varía y algunas respuestas pueden perderse. El borrador reconoce que la pérdida de paquetes sesga la estimación. La eficiencia se compra con una medida aproximada del tamaño del grupo.

También hay altas mientras se cuenta. El borrador parte del contador actual COUNT', compara el indicador E con la estimación anterior N, y aplica (E − N) / D con un amortiguador entero positivo D. Exige hacer esa corrección atómicamente respecto de nuevas inscripciones. Así evita que una actualización basada en el pasado borre a quien acaba de llegar. La precisión del registro interno mejora; sigue sin aparecer una constancia individual de recepción.

El ejemplo numérico deja ver el límite. El servidor estima 32 clientes y escoge Q=2: cada uno tiene una posibilidad entre cuatro de contestar. En realidad hay 18 activos. Cinco salen elegidos y una respuesta se pierde. Las cuatro que llegan producen E=16; con D=1, el contador cae de 32 a 16 y la observación grupal continúa. El número verdadero 18 solo existe para quien lee el ejemplo del documento. Un servidor real tendría sus cuatro respuestas y una hipótesis estadística.

El ahorro de paquetes traslada la decisión al operador

Con Q=0, todos los clientes activos quedan invitados a confirmar. Eso aumenta el tráfico de regreso y todavía admite pérdidas. Preguntar menos veces ahorra más pero envejece el contador. Un amortiguador mayor suaviza el cambio. La aplicación decide cuándo volver a preguntar y a partir de qué estimación cancela la observación grupal. Cancelar pronto puede dejar a interesados esperando actualizaciones; mantener un grupo vacío consume recursos. El protocolo entrega un instrumento, y el operador decide cómo gastarlo.

RFC 7252 define la maquinaria CoAP que sostiene este intercambio. El nuevo borrador reduce el costo de distribuir novedades Observe. Su contador estima interés, no recepción ni ejecución. Para elegir entre unicast y multidifusión en un tablero ambiental, una audiencia aproximada puede bastar. Una instrucción que debe cumplir un dispositivo concreto necesita pruebas de ese dispositivo, no una extrapolación del grupo.

Los documentos oficiales no miden una instalación ni sus patrones reales de pérdida. Una prueba controlada con clientes activos conocidos, respuestas seleccionadas y perdidas, y notificaciones recibidas permitiría medir el error antes de fijar umbrales. El trato queda a la vista: un aviso para todos abarata la red; saber quién sigue ahí se convierte en un sorteo.

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