Resumen

  • RFC 3528 autoriza al Directory Agent que acepta una actualización a devolver SrvAck al Service Agent antes de reenviar el registro, de modo asíncrono, a otros Directory Agents. El acuse termina una operación local, no una transacción distribuida.
  • Para afirmar algo más hacen falta comprobantes distintos: quién podía escribir, qué aceptó cada origen, qué recibió cada par, qué cubrió la anti-entropía, qué respondió cada consulta, cuánto tiempo quedaba, si el extremo era accesible y si la aplicación cumplió su objetivo.

Un acuse tiene una fuerza especial en los sistemas operativos: ofrece un punto final. El productor deja de esperar, libera recursos y registra éxito. Esa utilidad práctica invita a convertirlo en el final de una historia más larga.

En mSLP, sin embargo, el acuse puede aparecer al principio de la historia distribuida. RFC 3528, publicado en abril de 2003 con categoría Experimental, amplía SLPv2 con una malla completa por ámbito, propagación directa y anti-entropía. Su arquitectura distingue el ingreso del registro de su circulación.

El éxito pertenece a un diálogo concreto

El Service Agent envía un registro a un Directory Agent. El receptor que lo acepta es el accept DA. Si participa en la mejora de malla, después puede remitir el estado a otros agentes que comparten el ámbito.

La palabra decisiva es “después”. La propagación directa es asíncrona. El MDA de aceptación puede devolver SrvAck al MSA antes de enviar el Srv(De)Reg a otro MDA.

El comprobante no es débil: acredita una decisión local real. Contiene menos mundo del que suele asignarle un panel. No observa colas de pares, conexiones interrumpidas, consultas simultáneas ni salud del servicio anunciado.

Esperar a toda la malla antes de responder trasladaría cada fallo de réplica al escritor. El protocolo evita ese acoplamiento. La disciplina de evidencia debe acompañar la elección: baja latencia de aceptación a cambio de un estado de propagación que se prueba por separado.

El registro de auditoría necesita identificar al DA receptor, al emisor autenticado, los ámbitos, la huella de la carga, la política aplicada y la clase causal del acuse. Una fila llamada “publicado globalmente” no es una abreviatura; añade una observación inexistente.

El transporte ordenado sigue teniendo futuro

Los DAs pares mantienen una conexión persistente, fiable y ordenada que sirve todos sus ámbitos compartidos. Esto da continuidad a un flujo y evita que cada actualización necesite su propio acuse entre pares.

Pero una conexión fiable describe cómo viajan los bytes cuando la conexión opera. No afirma que un envío pendiente ya ocurrió, que el par fue autenticado correctamente o que el estado quedó disponible para una consulta.

Tras el intercambio inicial, el DA de aceptación reenvía las actualizaciones nuevas directamente a cada par pertinente, hasta que falla la ruta. El esquema es de un salto desde el origen de aceptación. No depende de una inundación transitiva sin límites.

Por eso la prueba de propagación debe hablar de cada par esperado: identidad, ámbitos comunes, sesión, posición del mensaje, resultado del envío y frontera recibida tras una reconciliación. El estado agregado “malla conectada” omite la actualización que importa.

Hay orden por origen, no un reloj universal

El accept ID combina la URL del DA que aceptó la actualización con una marca creciente asignada por ese agente. Las actualizaciones del mismo origen deben circular en ese orden.

Dos orígenes diferentes no comparten esa secuencia. Sus mensajes pueden propagarse en cualquier orden relativo. Una marca más grande en un DA no convierte su evento en posterior al de otro DA.

El MSA asigna además una marca de versión al registro. Esta permite elegir la versión más nueva del mismo objeto. El momento de llegada no sirve, porque una actualización vieja puede demorarse y aparecer después de la nueva.

Así surgen tres cronologías. La versión resuelve la evolución lógica del registro. El accept ID ordena lo aceptado por un origen. La hora de consulta capta el estado observado por un lector. Una base que conserve solo una fecha “updated_at” pierde la diferencia más importante.

RFC 3528 supone un único SA actualizador por registro. Si un producto admite varios escritores, necesita su propia política de conflicto y autoridad. El protocolo no entrega una solución que no diseñó.

El vector de resumen no es un certificado de salud

La anti-entropía usa un vector que registra, para cada DA de aceptación conocido, la marca más reciente recibida. Es una frontera compacta de recibos por origen.

Un receptor puede pedir estados posteriores a esas fronteras. Una solicitud completa incluye también los orígenes ausentes; una selectiva se limita a los accept IDs enumerados. Registrar cuál modalidad se usó es esencial.

Un intercambio selectivo puede concluir sin error y dejar sin revisar un origen entero. Decir únicamente “sincronización terminada” oculta esa elección. El universo de la petición forma parte del resultado.

El proveedor envía los estados solicitados en orden de accept ID y al final emite SrvAck por el procesamiento de la anti-entropía. Ese acuse no confirma lo mismo que el SrvAck del registro. Uno responde al escritor; el otro cierra una petición de reconciliación.

Ni siquiera un vector completo prueba que el servicio existe en el sentido operativo. Puede reflejar perfectamente el historial de un registro vencido, incorrecto o inaccesible. La frontera habla de recepción de estados, no del mundo descrito por ellos.

Una baja conserva memoria antes de desaparecer

Cuando se transfiere un registro durante recuperación, viaja con la vida útil restante. No recibe un plazo nuevo. Esta regla impide que la repetición de sincronizaciones renueve anuncios antiguos.

La baja tampoco se borra inmediatamente. Se conserva como estado eliminado para impedir que un registro anterior, retrasado en la red, lo resucite. La lápida se puede purgar al vencer el registro.

Aceptar la baja, distribuir la lápida y purgar el estado son operaciones separadas. También lo son dejar de devolver el registro en una consulta y eliminar cualquier caché de un consumidor.

Una evidencia rigurosa anota la identidad, la versión, el accept ID, la bandera de eliminación, la vida restante, el camino de reconciliación y consultas tomadas desde puntos relevantes. “Eliminado” necesita un sujeto y un instante.

El ámbito decide quién participa

Cada ámbito reúne una malla completa de MDAs que lo sirven. Una conexión puede transportar información de varios ámbitos comunes. El MSA necesita registrar con suficientes MDAs para que la unión de sus ámbitos cubra los propios; la propagación completa el resto.

Por tanto, una respuesta local no se extiende a agentes fuera del ámbito. Tampoco obliga a un User Agent a consultar el mismo directorio. Selección de ámbito, descubrimiento de DA y momento de consulta pueden cambiar el resultado.

La malla completa favorece simplicidad y fiabilidad, pero el RFC la sitúa en un tamaño general de decenas de MDAs o menos. No pretende resolver una población ilimitada. Esa cifra es orientación de diseño, no medición de una instalación actual.

Dividir un ámbito padre en dos ámbitos hijos cambia la obligación de registro. Un servicio que antes aparecía bajo el padre puede necesitar presencia en ambos hijos. La administración de ámbitos afecta directamente la superficie de descubrimiento.

Propagar amplía también una decisión equivocada

mSLP aprovecha la autenticación de SLPv2. Un MDA debería autenticar a otros MDAs antes del peering, autenticar a los MSAs antes de aceptar y propagar sus cambios, y un MSA debería autenticar al MDA elegido.

La conexión ordenada no sustituye ninguna de esas decisiones. Un peer técnico puede no ser miembro autorizado. Una firma válida puede pertenecer a una clave sin permiso para ese ámbito. Un registro autorizado puede seguir siendo semánticamente incorrecto.

El riesgo crece con la distribución. Comprometer un MDA puede afectar a todos los demás porque el estado aceptado se propaga. La malla replica disponibilidad y también replica la consecuencia de un control de ingreso defectuoso.

SLPv2 admite que el arranque sin configuración de seguridad previa puede exigir cierta confianza ciega. Esa limitación sitúa la gestión de claves y la política de verificación fuera de cualquier casilla automática de “protocolo seguro”.

IANA mantiene 0x0006 como identificador de la extensión Mesh-enhancement y cita RFC 3528. El registro coordina el número. No prueba implementación, activación, pertenencia legítima, convergencia ni resultado.

Descubrir es apenas el siguiente contrato

El Service Agent escribe y el User Agent lee. Son actores, rutas y momentos diferentes. Para demostrar visibilidad hay que consultar los DAs relevantes y conservar identidad del respondedor, ámbitos, filtro, huella de respuesta, versión, vida restante y hora.

Una respuesta de directorio indica que existe un anuncio. No establece una sesión con el servicio, no verifica su protocolo, no concede autorización al usuario y no termina la tarea de negocio.

El comprobante continúa por la resolución de destino, conectividad, handshake, prueba específica de salud y resultado de aplicación. Si la promesa comercial es “el servicio funciona”, una coincidencia en el catálogo es solo un antecedente.

Una cadena que no borre sus transiciones

Primero se documenta la autoridad: versión y estatus del protocolo, ámbitos, identidad del MSA, credenciales, política y autorización. Después se liga a la huella del registro, su versión, el DA receptor y el accept ID.

El SrvAck del escritor queda como recibo local inmutable. Cada par tiene un comprobante separado de envío y frontera. La anti-entropía conserva modalidad, vector, orígenes cubiertos, estados transferidos y su acuse final.

Las consultas y el uso del servicio cierran la secuencia. El equipo de directorio responde por estado y propagación; seguridad por identidades; el dueño del servicio por salud; la aplicación por el resultado del usuario.

El panel puede resumir, pero debe permitir abrir esa cadena. Si solo existe el primer acuse, el texto correcto es “aceptado aquí”. Cualquier alcance superior sigue siendo una hipótesis pendiente.

Límite de la evidencia

Este Artículo no identifica implementación, proveedor, operador, malla, agente, servicio, extremo, registro, incidente, caída, ataque ni resultado de cliente. No mide adopción, tamaño, demora, tasa de consulta, salud o impacto actual.

RFC 3528 se trata como protocolo Experimental publicado en abril de 2003, no como Internet Standard. Los valores predeterminados de 200 segundos para keepalive y 300 para timeout proceden del texto; no describen una configuración real.

Los registros y metadatos documentales fijan identidades y asignaciones, no la conducta del código en ejecución.

Las notas de Heng Lu sobre autoridad y running code se declaran como lente editorial. Ayudan a formular el límite del recibo, pero no prueban intención del IETF ni conformidad de ningún sistema.

La conclusión es deliberadamente estrecha: aceptación, propagación, visibilidad, alcance y resultado son estados comprobables por separado.

Fuentes