Resumen

  • sctp_peeloff entrega una asociación SCTP existente a un socket individual; no establece otra asociación para sustituirla.
  • Las operaciones posteriores de datos y control pasan al nuevo descriptor. Cerrar el socket compartido anterior no termina la asociación extraída.

Un procedimiento de parada puede cerrar el descriptor previsto y, aun así, dejar fuera parte del trabajo que sus responsables creían haber incluido. En SCTP hay una explicación concreta: una asociación se separó antes del socket común y ahora depende de otro descriptor. El cierre no ha fallado. Ha actuado sobre un conjunto más pequeño del que seguía figurando en el plan operativo.

La RFC 6458 describe esa separación mediante sctp_peeloff. Una asociación establecida en un socket de uno a muchos pasa a disponer de un socket de uno a uno. La comunicación no vuelve a negociarse por ese solo hecho. Cambia la interfaz local con la que la aplicación la maneja.

El detalle importa porque la separación suele justificarse por un beneficio inmediato: tratar aparte una carga que incomoda al conjunto. Pero ese mismo movimiento cambia el perímetro de las instrucciones futuras. La decisión está incompleta si alguien aprueba la independencia de recursos y nadie acepta la responsabilidad de terminar la actividad que acaba de independizarse.

El atasco puede estar en la asignación compartida

El modelo de uno a muchos permite atender varias asociaciones mediante un socket. Cuando una operación lo requiere, el identificador de asociación permite seleccionar la correspondiente. Es una economía de gestión, no una demostración de que cada asociación tenga recursos aislados.

La sección 3.3 estudia una implementación que comparte la asignación del búfer de salida. Una asociación detenida puede consumir esa capacidad e impedir que las demás envíen. Utilizar modo no bloqueante no elimina el problema: evitar que una llamada espere no crea espacio independiente donde antes había un recurso común.

El documento contempla varias respuestas. La implementación puede reservar capacidad por asociación; el protocolo de aplicación puede limitar los datos no leídos; la aplicación puede trabajar con sockets individuales desde el principio o separar una asociación antes de un intercambio voluminoso que pudiera detenerse. Cada alternativa coloca el límite en un sitio distinto.

No es una promesa universal sobre rendimiento. La premisa es la asignación que haga la implementación. El texto no permite asegurar cómo se trasladarán las colas existentes, cuánta memoria usará un sistema concreto ni qué incremento de velocidad producirá la separación. Sí permite identificar el recurso compartido que se quiere dejar de tratar como un único ámbito operativo.

Una asociación conocida recibe otro descriptor

En sctp_peeloff, la aplicación indica el socket original y la asociación que desea extraer. Si la operación tiene éxito, obtiene un descriptor no negativo; si falla, obtiene menos uno y una indicación de error. A diferencia de la aceptación ordinaria de una nueva llegada, se elige una asociación que ya estaba establecida.

La sección 9.2 exige que todas las operaciones posteriores de datos y control sobre esa asociación utilicen el nuevo socket. Añade la consecuencia que debe llegar al procedimiento de parada: cerrar el socket original no termina la asociación separada.

Pensemos en un servicio hipotético que mantiene muchas asociaciones juntas y aparta un intercambio especialmente pesado. Más tarde cierra el socket de entrada común. Esa orden no alcanza al intercambio apartado por el mero hecho de que antes perteneciera al grupo. El servicio necesita conservar su descriptor individual entre los recursos que todavía controla. El ejemplo ilustra el contrato de la interfaz; no describe una instalación observada.

La continuidad puede ser deliberada y útil. No debe confundirse automáticamente con una fuga. Lo que hay que determinar es si alguien decidió conservar ese trabajo o si simplemente dejó de aparecer en el inventario desde el que se ejecuta el cierre.

Las opciones tienen un ámbito, no una memoria organizativa

La RFC explica que las opciones de los niveles socket e IP se aplican al socket correspondiente. En el modelo compartido afectan a sus asociaciones; en el individual, a la asociación representada allí. Las secciones de búferes también advierten de diferencias de implementación para el modelo de uno a muchos.

SCTP_AUTOCLOSE ofrece un caso especialmente instructivo. La sección 8.1.8 lo documenta únicamente para sockets de uno a muchos. Mide inactividad de datos de usuario; el cero predeterminado lo desactiva y los valores no nulos se expresan en segundos. Para recibir avisos de esas terminaciones, la aplicación necesita las notificaciones de cambio de asociación.

Eso no demuestra que, al separar una asociación, un temporizador ya activo se cancele, se reinicie o se herede de determinada manera. Los pasajes examinados no establecen ese comportamiento. Lo responsable es comprobar la política de vida útil del nuevo socket en la implementación utilizada, no presentar el ajuste anterior como una garantía que viaja por sí sola.

También hay que precisar qué significa cerrar. El cierre ordinario de un socket individual inicia la terminación ordenada de SCTP y retira el descriptor de las operaciones posteriores. Con SO_LINGER activado y tiempo cero, close provoca en cambio un aborto. Un tiempo positivo limita la espera de la llamada, no necesariamente la duración completa de la terminación del protocolo: esta puede continuar después del retorno.

La interfaz shutdown descrita permite conservar el descriptor para notificaciones durante la terminación. Sin embargo, SHUT_WR inicia el cierre completo del protocolo SCTP, no el semicierre de TCP. Y ninguno de esos estados, por sí mismo, certifica el resultado de una operación de negocio.

El alcance de la evidencia

La ficha del RFC Editor identifica un documento Informational de diciembre de 2011. No es un inventario actualizado de implementaciones. La lista de erratas consultada contiene correcciones verificadas en otros pasajes, sin una corrección directa de la sección 9.2. Las entradas retenidas para una actualización y las rechazadas no tienen el mismo valor que una corrección aceptada.

La lectura de gobierno es posterior a esos hechos. En su ensayo sobre el problema de agencia, Lu Heng relaciona las decisiones con la exposición a sus consecuencias. Aplicado a esta interfaz, obliga a preguntar si quien acepta la separación conoce al responsable de su cierre. No autoriza a atribuir intenciones a los ingenieros.

Su explicación de por qué existe BTW Media propone atender a la realidad antes que a la defensa de una posición. Aquí, la realidad relevante es el conjunto de descriptores que sigue controlando asociaciones, no la frase tranquilizadora «el punto de entrada ya está cerrado».

Separar puede ser la elección correcta. Lo que no puede mantenerse sin revisión es el mapa de responsabilidades anterior a la separación.