STSN

I numeri di sequenza set e test (STSN) vengono usati nelle sessioni con il profilo TS (Transmission Service Profile) 4 per le applicazioni per mantenere i numeri di sequenza di elaborazione delle transazioni tra le sessioni. Ciò consente a entrambi i partner della sessione di individuare la quantità di dati persi dopo una sequenza CLEAR o UNBIND-BIND .

Il messaggio STSN è l'unico che può reimpostare tali numeri di sequenza di elaborazione delle transazioni. BIND, UNBIND e CLEAR non influiscono su di essi.

Se l'applicazione vuole mantenere tali numeri di transazione, deve specificare l'opzione APPLTRAN nella risposta OPEN(PLU) OK. L'host può inviare STSNdopo bind oCLEAR prima di inviare SDT per impostare o testare i numeri di transazione dell'applicazione. Il nodo locale reimposta i numeri della sequenza di sessione interna su zero alla ricezione di BIND o CLEAR. Quando il nodo locale riceve un stSN che specifica SET (o SET e TEST) per una metà sessione, reimposta il numero di sequenza di sessione interno corrispondente.

A meno che entrambe le azioni della metà sessione non vengano ignorate (il byte dell'azione è 0x00), la richiesta STSN viene passata all'applicazione (purché sia stata specificata APPLTRAN), con il byte di azione e i due numeri di sequenza della richiesta, come status-control (STSN) . Per altre informazioni, vedere Status-Resource. L'applicazione deve esaminare il byte dell'azione per determinare se l'azione viene ignorata, impostata, test o impostata e test. L'applicazione deve inviare una risposta positiva (Status-Control(STSN) a STSN, con i numeri di sequenza sensati, se necessario (senso o set e test). Il nodo locale è responsabile della generazione del codice di risultato corretto per il provider di servizi di sicurezza token di sicurezza.The local node is responsible for generate the correct result code for the STSN RSP.

Si noti che l'applicazione deve eseguire prima la parte sense di STSN (esaminando rispettivamente i bit 0 e 2 del byte dell'azione per il flusso da secondario a primario e da primario a secondario). Viene quindi eseguita la parte set del servizio token di sicurezza (esaminando i bit 1 e 3 del byte dell'azione).

L'applicazione deve incrementare i numeri di transazione durante l'invio e la ricezione di normali unità richiesta/risposta di flusso dall'host. Si noti che i messaggi status-Control corrispondenti alle normali richieste di controllo del flusso di dati (DFC) causano l'incremento dei numeri di transazione. Il numero di sequenza viene segnalato nei messaggi DATAFMI e nei messaggi Status-Acknowledg . L'applicazione deve tenere presente che, se un messaggio dall'host non riesce a ricevere i controlli (e viene convertito in un messaggio SDI ), il protocollo di accesso alla rete secondaria (SNAP)-2.1 elimina il resto della catena dall'host e l'applicazione potrebbe perdere alcuni numeri di sequenza. Di conseguenza, l'applicazione deve reimpostare il numero di transazione da primario a secondario dai dati in uscita successivi dopo l'elaborazione di un messaggio SDI .

Si noti che il secondo byte del flag dell'applicazione non è valido per Status-Control(STSN). Viene usato per il byte del controllo STSN .

Vedere anche

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