RQR e CLEAR

Un'applicazione che usa il profilo del servizio di trasmissione (profilo TS) 4 può richiedere il ripristino della sessione inviando Status-Control(RQR). Il nodo locale lo presenta all'host come richiesta RQR . Si noti che, se l'applicazione ha ricevuto un riconoscimento dello stato critico(Nack-2), questa opzione non può essere accettata perché il nodo locale invierà una richiesta Close(PLU) immediatamente dopo status-acknowledgement(Nack-2) all'applicazione e la connessione dell'unità logica primaria (PLU) non sarà più valida. Il messaggio RQR richiede all'host di reimpostare la sessione inviando una richiesta CLEAR , come illustrato nella figura seguente.

La ricezione di CLEAR fa sì che l'applicazione reimposta lo stato della sessione su quello che segue bind,Open(PLU).

Un altro modo per consentire all'applicazione di gestire le condizioni di errore consiste nell'richiedere un UNBIND inviando Status-Control(RSHUTD). Per altre informazioni, vedere Terminazione avviata dall'applicazione. Si noti che questo potrebbe non richiedere all'host di fornire un nuovo BIND, a seconda della configurazione host. Potrebbe essere necessaria una nuova richiesta SSCP, ad esempio LOGON.

Nella figura seguente l'applicazione richiede il ripristino eseguendo Status-Control(RQR). L'host invia CLEAR e l'applicazione deve reimpostare la sessione in modo che sia stata eseguita l'istruzione BIND (Open(PLU)). In questo caso, l'applicazione è ora tra parentesi quadre e in attesa di avviare il traffico dati (SDT).

Immagine che mostra il ripristino delle richieste dell'applicazione eseguendo Status-Control (RQR).
L'applicazione richiede il ripristino eseguendo Status-Control (RQR)

Vedere anche

CANCEL applicazione
Direzione dopo aver ricevuto una risposta negativa
Direzione dopo aver inviato una risposta negativa
Errore critico
STSN
Errore del servizio di collegamento
Errore del nodo locale
Errore del client