Resumen

  • RFC 5351 permitió resolver un pool handle a una lista de Pool Elements y elegir candidatos según una política. RFC 5352 permitió reutilizar entradas de caché que todavía no fueran antiguas. Esa vigencia describe información de protocolo dentro de una ventana, no la capacidad actual del servidor.
  • La detección de fallos y la obtención del siguiente servidor reducen el trabajo común de las aplicaciones, pero no determinan si la operación anterior se confirmó. Estado transaccional, contexto de seguridad, compatibilidad y repetición segura permanecen en la aplicación.
  • Una recuperación verificable necesita conservar el origen y la edad de la resolución, la política, la conexión real, el principal autenticado, el límite de commit, el estado transferido, la idempotencia y la prueba externa del resultado.

“No caducada” era una regla de uso, no una medición física

RFC 5352 prevé una caché para evitar una consulta ENRP en cada envío. Cada entrada tiene un temporizador. Si se considera antigua, la implementación puede actualizarla mientras responde o puede bloquear al usuario hasta obtener datos nuevos. Si no es antigua, normalmente utiliza la entrada.

El diseño reconoce un intercambio inevitable. Consultar siempre aumenta tráfico y latencia, y aun así un servidor puede fallar justo después de la respuesta. Reutilizar información reciente mejora rendimiento, pero acepta una ventana entre el estado registrado y la realidad del instante.

El error conceptual aparece cuando la interfaz transforma “no ha superado el umbral” en “está vivo”. La primera frase habla de una política local de caché. La segunda exige una observación del endpoint. Ninguna de las dos prueba que la aplicación esté preparada, que sus datos estén al día o que acepte al usuario.

Una investigación necesita la edad exacta, el umbral, el ENRP de origen y el conjunto que se recibió. Sin esos campos, dos incidentes distintos —una entrada dentro de ventana y una entrada conservada más allá del límite— se vuelven indistinguibles.

El handlespace también tenía tiempo

Los servidores ENRP sincronizan altas, bajas y datos del espacio de handles. Intercambian presencia, comparan sumas de identidades y solicitan la parte incoherente cuando detectan diferencias. Si un servidor falla, los restantes negocian quién toma sus elementos.

Esto construye un registro distribuido tolerante a fallos, no una visión instantánea. Una baja puede estar propagándose. Un alta puede existir en un servidor antes de aparecer en otro. Un elemento puede responder al keep-alive y caer antes del próximo contacto de aplicación.

El pool handle, además, solo es válido en su ámbito operativo. Es una cadena única en ese espacio, no un nombre universal. RFC 5351 no resolvió la administración global de handles y RFC 3237 deja la interoperabilidad entre espacios a mecanismos externos.

La marca temporal y el ámbito son parte del dato. Presentar una dirección sin ellos permite que un registro local y reciente sea interpretado como autoridad global y actual.

La lista devolvía candidatos según conocimiento disponible

Cuando el Pool User solicita resolución, el ENRP devuelve uno o más elementos a partir de su conocimiento. La política puede rotar, ponderar, elegir al azar, priorizar o usar carga. La respuesta organiza posibilidades.

RFC 5356 advierte de manera indirecta contra una lectura excesiva. “Carga” tiene un rango común, pero su definición es específica de la aplicación. Los miembros de un pool deben compartir esa definición; el protocolo no decide si significa usuarios, CPU, memoria u otro recurso.

Un valor menor puede coexistir con una réplica atrasada, un bloqueo de base de datos, una dependencia caída o una autorización agotada. La selección es correcta dentro de su función y, a la vez, incapaz de predecir el resultado de una operación concreta.

Por eso el registro operativo debe conservar la lista completa, el criterio y los valores usados. Si solo queda la dirección elegida, el análisis pierde la oportunidad de distinguir un fallo del candidato de un modelo de selección mal alineado con la carga real.

Encontrar otro elemento no resolvía el punto de commit

El ejemplo de RFC 5351 sustituye una lista fija de servidores por primitivas parecidas a GETPRIMARYSERVER y GETNEXTSERVER. Esta última informa del fallo anterior y obtiene la siguiente dirección según la mejor información disponible.

La expresión “mejor información” es deliberadamente limitada. No conoce necesariamente el estado de la transacción. Si la conexión desapareció tras enviar una escritura, el servidor pudo no recibirla, pudo validarla o pudo completar el efecto y perder la respuesta.

Repetir en un elemento nuevo requiere una regla de aplicación: identificador estable, deduplicación, consulta de estado o compensación. Un protocolo de descubrimiento no puede inventar esa regla. RFC 5351 dice expresamente que el failover que depende del estado o del estatus transaccional necesita conocimiento específico.

La métrica de disponibilidad debe separar “tiempo hasta otra dirección” de “tiempo hasta una conclusión correcta”. La primera puede ser excelente mientras la segunda queda indeterminada.

El cookie más reciente podía ser anterior al hecho decisivo

RSerPool ofrece un cookie opcional. El elemento envía información de estado, el usuario guarda solo la última y la presenta al nuevo elemento durante el failover. Para el usuario es opaca.

Guardar “la última recibida” no garantiza guardar el último estado creado. El elemento pudo validar una operación después de emitirla. El mensaje nuevo pudo perderse con la conexión. La periodicidad crea una distancia explícita entre el checkpoint y el momento del fallo.

La firma recomendada protege origen e integridad. No prueba actualidad ni contenido suficiente. RFC 5352 deja los detalles de verificación fuera de alcance, y el soporte de cookie o business card no es obligatorio de manera uniforme.

Una aplicación seria debe versionar el formato, declarar su semántica, fijar caducidad, rotar claves, probar compatibilidad y registrar qué commit representa. De lo contrario, un objeto criptográficamente correcto puede inducir una repetición incorrecta.

Darse de baja no terminaba las sesiones anteriores

RFC 3237 exige que un Pool Element que se da de baja siga atendiendo a usuarios conectados antes de la baja, mientras las conexiones nuevas se dirigen a otro. El objetivo es un drenaje sin interrupción.

Eso demuestra que membresía y trabajo activo son estados distintos. Un snapshot del handlespace no enumera todas las sesiones en curso. Un orquestador que apaga un elemento apenas desaparece del pool puede destruir conexiones que el modelo esperaba preservar.

También ocurre lo contrario: un elemento registrado puede no haber terminado su calentamiento, migración o precarga. La inscripción lo vuelve elegible para selección; una puerta de readiness de aplicación debe decidir cuándo puede aceptar cada clase de tráfico.

Los procedimientos de despliegue tienen que registrar ambos relojes: elegibilidad para nuevas sesiones y finalización de sesiones anteriores. Reducirlos a una bandera “in/out” elimina justamente la evidencia que permite un drenaje seguro.

SCTP protegía otro nivel de continuidad

La suite utiliza SCTP en relaciones importantes. SCTP ofrece multihoming, heartbeats y gestión de rutas. Puede cambiar el camino hacia el mismo endpoint sin cambiar de servidor ni de asociación.

RSerPool, en cambio, puede seleccionar otro Pool Element. El primer movimiento conserva más estado de transporte; el segundo cruza una frontera de proceso y posiblemente de almacenamiento. Confundirlos lleva a esperar que la recuperación de ruta transporte el estado de aplicación, o que una nueva asociación herede el contexto de la anterior.

RFC 9260 sustituyó a RFC 4960 como base actual de SCTP. Las extensiones de fiabilidad parcial, reconfiguración y API añaden herramientas, pero no convierten la continuidad de transporte en exactamente-una-vez para la aplicación.

La telemetría debe nombrar el evento: cambio de dirección SCTP, pérdida de asociación, reselección de Pool Element, restauración de estado o repetición de operación. “Failover” solo no permite saber qué continuidad se logró.

Autenticar el pool no autorizaba la operación

RFC 5355 muestra cómo altas falsas, servidores ENRP maliciosos, resolución alterada o replay pueden contaminar el sistema. Exige autenticación y autorización entre participantes y describe TLS con claves precompartidas en un dominio administrativo.

La protección es esencial: evita que cualquiera se anuncie como elemento o devuelva una dirección arbitraria. Sin embargo, un nodo autorizado para pertenecer al pool no queda autorizado para ejecutar toda acción de negocio en nombre de todo usuario.

Al conectar con el reemplazo, el principal de aplicación debe autenticarse y su permiso debe reevaluarse. El contexto antiguo puede haber expirado, sido revocado o estar vinculado al primer servidor. RFC 3237 deja el intercambio del contexto de seguridad fuera de alcance.

La arquitectura segura conserva la separación entre autoridad de infraestructura, identidad del usuario, permiso sobre la operación y permiso para mover estado. La disponibilidad no debe abrir un atajo entre ellas.

De la resolución al resultado había diez pruebas

Primero, el handle debe existir en el ámbito correcto. Segundo, el elemento debe figurar en la vista consultada. Tercero, la resolución o caché debe devolverlo bajo una política conocida. Cuarto, debe ser alcanzable. Quinto, debe hablar la aplicación y autenticar al principal. Sexto, debe conocerse el estado de la operación anterior. Séptimo, el estado transferido debe ser auténtico, fresco, completo y compatible. Octavo, la repetición debe ser segura. Noveno, el efecto debe quedar durable. Décimo, una observación independiente debe confirmar el resultado.

La caché participa en el tercer recibo. No puede sustituir los siete siguientes. Esta ubicación exacta evita culparla por todo y evita atribuirle autoridad que no tiene.

IANA mantiene los códigos de mensajes, parámetros, errores y políticas RSerPool. El registro demuestra coordinación de símbolos. No demuestra que un pool esté desplegado ni que su información esté actualizada.

Las notas de Lu Heng sobre especificación mínima y capas de realidad ayudan a mantener el mapa pequeño: el protocolo coordina handles y mensajes; la aplicación conserva la decisión sobre estado y efecto. Son lentes declaradas, no fuentes históricas; los RFC y IANA sostienen los hechos.