Resumen

  • Observe mantiene una representación actual de un recurso CoAP con entrega de mejor esfuerzo; no garantiza que el cliente vea cada transición.
  • La secuencia de 24 bits, la condición temporal de 128 segundos y Max-Age permiten ordenar y limitar la confianza en lo recibido, pero no forman una cola duradera.
  • Si una transición ausente tiene consecuencias de seguridad, facturación o auditoría, la aplicación necesita historial, confirmación a nivel de negocio o recuperación explícita además de Observe.

La eficiencia tiene una frontera escrita

El cliente registra su interés mediante GET, Observe igual a cero y un token. Una respuesta exitosa que también contiene Observe confirma que el servidor mantiene una entrada para ese punto final y token. Las notificaciones posteriores son respuestas adicionales a la petición original. Si el servidor no acepta la relación, responde como a un GET normal sin la opción, y el cliente debe recurrir a consultas periódicas.

Para dispositivos con poca batería y redes estrechas, eliminar sondeos sin cambios es una ganancia concreta. El servidor envía una representación cuando el recurso cambia; los intermediarios pueden compartir una observación ascendente entre varios clientes. La RFC conserva así el modelo REST y la posibilidad de usar caché.

Pero el documento declara lo que no construye. Observe no pretende sustituir sistemas generales de publicación y suscripción. La entrega es de mejor esfuerzo. El servidor intenta mantener al cliente cerca del estado real y, si el recurso deja de cambiar, la coherencia acaba convergiendo. Durante congestión o cambios demasiado rápidos puede saltar cualquier cantidad de estados intermedios.

Por eso “ahora está normal” y “nunca estuvo crítico” son afirmaciones diferentes. La primera puede estar respaldada por la última representación fresca. La segunda exige historial que Observe no promete.

El valor pequeño y el silencio largo

Cada notificación 2.xx lleva el token de la relación y un valor Observe. El servidor toma los 24 bits menos significativos de una secuencia estrictamente creciente. El cliente usa aritmética serial para decidir cuál fue enviada más recientemente. Así puede reconocer que un valor pequeño después del desbordamiento es posterior a uno grande anterior.

La comparación incorpora el tiempo local. Si han pasado más de 128 segundos desde la notificación aceptada como más fresca, el cliente puede considerar nueva la siguiente llegada sin depender de la diferencia serial. El límite evita que un espacio de 24 bits quede ambiguo tras un silencio largo. No mide la hora del suceso físico ni cuenta cambios omitidos.

El servidor tampoco puede recorrer más de la mitad del espacio en menos de 256 segundos. Es una restricción para que el orden sea interpretable, no un mecanismo de retención. Un reinicio, una pérdida de token o una decisión del proxy todavía necesitan pruebas de interoperabilidad.

Max-Age retira una suposición

Max-Age indica durante cuánto tiempo es aceptable que la representación observada difiera del recurso. Cuando la edad supera ese valor, el cliente no debe suponer que refleja el estado actual. Puede refrescar o volver a registrar la misma relación.

La expiración no demuestra que hubo cambio. Tampoco demuestra pérdida de paquete o fallo del servidor. El estado profesional es “desconocido” hasta obtener evidencia nueva. Convertirlo automáticamente en normal, crítico o cero es una política del producto que debe ser visible y autorizada.

Una notificación confirmable tampoco llena el hueco. Su ACK confirma llegada del mensaje CoAP correspondiente. Observe permite notificaciones confirmables o no confirmables con independencia del tipo de la petición. Ningún acuse confirma una serie histórica que el servidor estaba autorizado a comprimir.

Cancelar no es borrar simultáneamente

El cliente puede olvidar la observación y rechazar después una notificación confirmable desconocida con Reset. También puede enviar GET con el mismo token y Observe igual a uno para darse de baja. Si Reset o la petición se pierden, el servidor puede mantener la entrada y seguir transmitiendo. La relación termina por reintentos, confirmaciones y recogida de estado, no por una transacción global instantánea.

Esto importa en un servidor pequeño que conserva miles de observadores y en un equipo de radio que paga cada despertar. Una aplicación que requiere terminación rápida debe mostrar el resultado de la baja y reintentar de forma acotada.

Cada salto fabrica su propia frescura

Un intermediario puede registrar una sola observación hacia el origen y distribuirla a varios clientes. Cada salto decide número y tipo de notificaciones, genera sus valores Observe y calcula Max-Age según su copia local. La escalabilidad aumenta, pero también aparece una frontera de evidencia.

El cliente no recibe necesariamente la secuencia originaria. Recibe una representación que el proxy afirma actual bajo reglas válidas. Un producto responsable indica si la última actualización vino del origen, de una validación de caché, de un refresco o de un nuevo registro.