Resumen

  • RFC 3082 permite que un agente de usuario se suscriba a los cambios en los servicios en vez de consultar continuamente, con diseños distintos para redes con Directory Agent y sin él.
  • Si desaparece un DA, los agentes de servicio ya avisados pueden seguir enviando anuncios, pero uno nuevo puede no recibir la suscripción. Que sigan llegando los avisos antiguos no demuestra que se mantenga la cobertura de servicios nuevos.

Consultar no es recibir un flujo

Service Location Protocol partía de una asimetría deliberada: los agentes de servicio (SA) publicaban servicios y los agentes de usuario (UA) preguntaban por ellos cuando los necesitaban. Una aplicación que quisiera actualizar su vista cada vez que aparecía o desaparecía un servicio tenía que consultar la red periódicamente. Publicado en marzo de 2001 como protocolo experimental, RFC 3082 propuso un flujo de cambios para evitar esas consultas repetidas. No es un estándar de Internet.

Pasar de preguntar a escuchar parece sencillo, hasta que llega la pregunta sobre un agente nuevo: ¿quién le dice que hay un UA escuchando? La respuesta depende de si la red utiliza Directory Agents (DA). Esas dos topologías no guardan la misma información en el mismo lugar.

Dos topologías, dos costes

Sin DA, los SA anuncian registros y bajas mediante multidifusión IP —o difusión IPv4 cuando no se dispone de multicast—. Los UA reciben un conjunto amplio de avisos y filtran por tipo de servicio y ámbito. Así no hace falta un intermediario que informe a los SA nuevos de cada suscripción, pero los receptores deben procesar avisos ajenos y el alcance de multicast se vuelve decisivo.

En una red con DA, el UA adjunta la extensión Subscribe a una solicitud de servicio. El DA responde con grupos multicast NotifyAt para el tipo y los ámbitos solicitados. Puede anunciar la suscripción a los SA existentes; cuando se registra un SA nuevo que coincide, el acuse SrvAck puede incluir la misma instrucción. El DA también notifica si un anuncio expira sin una baja ordenada. La mayoría de los cambios los siguen enviando los SA, no un DA que actúe como retransmisor central.

El reparto reduce la carga de un único intermediario, pero reparte también el estado. El DA mantiene suscripciones; los SA ya informados recuerdan grupos; el UA se une a ellos; y la asignación y el plazo del grupo multicast constituyen otro estado. Para reducir anuncios NotifyAt duplicados, el DA espera un intervalo uniforme aleatorio de cero a tres segundos y escucha mensajes coincidentes de otros DA. Suprimir duplicados no equivale a replicar la tabla de suscripciones.

Qué se pierde y qué continúa

La sección 10 describe un fallo parcial con precisión. Cuando desaparece un DA de forma imprevista, se pierde la información de suscripción de los UA que almacenaba. Sin embargo, los UA continúan recibiendo avisos de los SA existentes, porque esos SA ya conocían NotifyAt. Un SA nuevo no recibe la suscripción, salvo que otro DA también conserve esa información.

El UA quizá no descubra un DA alternativo hasta que haga una solicitud activa. Por tanto, un servicio puede registrarse después de perderse el DA anterior y antes de que el UA encuentre el sustituto y renueve la suscripción. La secuencia de avisos parece viva porque los servicios antiguos siguen apareciendo; el recién llegado puede no aparecer nunca.

La recuperación protege a los emisores ya conocidos. Continúan hasta que venza la suscripción; si no hay otro DA disponible, ignoran ese vencimiento y siguen hasta descubrir uno nuevo. Tras registrarse, el SrvAck informa al SA de si el UA renovó. Pero la RFC reconoce una ventana residual: los SA que arrancan entre la vuelta del DA y la renovación del UA siguen sin ser informados. Si necesita enterarse de absolutamente todos los servicios, el UA debería suscribirse a cada nuevo DA que admita sus ámbitos. Tener varios equipos no replica automáticamente el estado.

Un aviso no completa una transacción

El resto del mecanismo exige la misma cautela. Los anuncios multicast se repiten durante quince segundos con intervalos que aumentan exponencialmente. Según la RFC, esto eleva la probabilidad de que llegue un mensaje; no garantiza la entrega ni crea un registro persistente de eventos. Una lista de atributos puede exceder el tamaño de un paquete UDP: el bit de desbordamiento avisa al UA de que quizá tenga que consultar después al SA o al DA.

La RFC también prevé bloques de autenticación verificables, pero autenticar un aviso no demuestra que todos los oyentes lo recibieran, que el endpoint siga accesible ni que una operación de la aplicación terminara correctamente.

Conviene separar la suscripción del UA, el estado de tipo y ámbito en el DA, la instrucción NotifyAt que llega al SA, la pertenencia al grupo multicast, el evento emitido, su recepción efectiva, una consulta posterior si faltan atributos y el intercambio de servicio final. La especificación conecta algunos pasos; no los convierte en un recibo integral.

Las dos partes del título son compatibles. RFC 3082 no dice que la pérdida de un DA silencie toda la red: los SA existentes pueden continuar y otros DA pueden preservar parte de la cobertura. Su punto es más acotado: la continuidad de quienes ya estaban informados no equivale a cubrir a quienes llegan después. Sustituir consultas periódicas por notificaciones cambia dónde se recuerda quién escucha y qué paso de recuperación debe restaurar ese recuerdo.

Fuentes

Texto e historial: RFC 3082, registro del RFC Editor, historial en Datatracker, RFC 2608: SLPv2, RFC 2119, RFC 2373, RFC 2730 y RFC 2908. Lentes editoriales, no pruebas del comportamiento de SLP: Lu Heng, Running-Code Primacy y On Reality Layers.