RQR y CLEAR

Una aplicación que usa el perfil de servicio de transmisión (perfil de TS) 4 puede solicitar la recuperación de la sesión mediante el envío de Status-Control(RQR) . El nodo local presenta esto al host como una solicitud RQR. Tenga en cuenta que, si la aplicación ha recibido un mensaje Status-Acknowledge(Nack-2) crítico, esta opción no se puede adoptar porque el nodo local enviará a la aplicación una solicitud Close(PLU) Request inmediatamente después de Status-Acknowledge(Nack-2) , y la conexión de la unidad lógica principal (PLU) ya no será válida. El mensaje RQR solicita al host que restablezca la sesión mediante el envío de una solicitud CLEAR, como se muestra en la ilustración siguiente.

La recepción de CLEAR hace que la aplicación restablezca su estado de sesión al que sigue a BIND, es decir, Open(PLU) .

Otra manera de que la aplicación se ocupe de las condiciones de error es solicitar un comando UNBIND mediante el envío de Status-Control(RSHUTD) . (Para más información, vea Terminación iniciada por la aplicación). Tenga en cuenta que es posible que esto no requiera que el host proporcione un nuevo comando BIND, en función de la configuración del host. Es posible que se requiera una nueva solicitud SSCP (por ejemplo, LOGON).

En la ilustración siguiente, la aplicación solicita la recuperación mediante la emisión de Status-Control(RQR) . El host envía CLEAR, y la aplicación debe restablecer su sesión para que el estado sea el siguiente a BIND (Open(PLU) ). En este caso, la aplicación ahora está entre corchetes y a la espera de iniciar el tráfico de datos (SDT).

Solicitudes de aplicación mediante la emisión de Status-Control(RQR)

Consulte también

Application CANCEL
Dirección después de recibir una respuesta negativa
Dirección después de enviar una respuesta negativa
Error crítico
STSN
Error del servicio de vínculo
Error del nodo local
Error de cliente