Condividi tramite


Caratteristiche della sessione SSCP

Per i nodi SNA di tipo 2.1, la sessione del punto di controllo dei servizi di sistema (SSCP) usa il profilo di gestione delle funzioni (FM) 0 e il profilo del servizio di trasmissione (profilo TS) 1. Questa combinazione di profili fornisce le caratteristiche di sessione seguenti:

  • Entrambe le sessioni di metà primaria e secondaria usano la modalità richiesta immediata.

  • Le metà delle sessioni primarie e secondarie usano entrambe la modalità di risposta immediata.

  • Sono consentite solo catene di unità richiesta singola di risposta definita.

  • La dimensione massima dell'unità richiesta è limitata a 256 byte.

  • Le unità richiesta di controllo del flusso di dati non sono supportate.

  • La pacing non è supportata.

  • Gli identificatori vengono usati (anziché numeri di sequenza) nei flussi normali.

    Ciò implica che la connessione SSCP presenta le caratteristiche seguenti:

  • Tutti i messaggi di dati hanno il set di campi ACKRQD (ACKRQD).

  • Tutti i messaggi di dati hanno l'indicatore della catena iniziale (BCI) e i flag dell'applicazione ECI (End Chain Indicator).

  • I messaggi di controllo dello stato non vengono trasmessi sulla connessione.

  • Messaggi di sessione di stato dal nodo locale all'applicazione segnalano solo le modifiche nello stato di attivazione della sessione.

  • I protocolli di concatenamento, parentesi, conferma e ripristino (descritti in Connessione PLU) non si applicano.

    Usando la connessione SSCP, l'applicazione può inviare e ricevere messaggi di dati corrispondenti alle richieste di dati fmd (FMD NS) e alle richieste di dati FMD. Esempi di richieste NS (servizi sessione) FMD sono:

  • INIT-SELF. Le richieste dal database secondario all'host SSCP richiedono che SSCP assista all'avvio di una sessione alla PLU host, richiedendo in modo efficace un'associazione. Per altre informazioni, vedere Apertura della connessione PLU.

  • TERMINE SELF. Richieste dal database secondario all'host SSCP che richiedono che la sessione PLU-SLU venga terminata con un UNBIND. Per altre informazioni, vedere Chiusura della connessione PLU.

  • Richieste codificate con caratteri. Richieste come accesso, disconnessione o comandi di test dalla visualizzazione secondaria o un prompt di accesso dall'applicazione host.

  • NOTIFICARE. Richieste usate dal database secondario per notificare all'host SSCP che un dispositivo è disponibile dopo che un'associazione è stata rifiutata con codice sense 0x0845, ad esempio, in cui un emulatore di dispositivo supporta la disattivazione logica.

    Il nodo locale invia una richiesta NOTIFY a SSCP per conto dell'lu ogni volta che lo stato di connessione SSCP dell'applicazione cambia mentre l'lu è attiva. Una notifica (chiave vettoriale 0x0C con byte 5 impostata su 0x03), che può fungere da LU secondario, viene inviata nei casi seguenti:

  • Quando viene ricevuta una richiesta Open(SSCP) quando l'unità lu è già attiva.

  • Quando viene accettata una richiesta ACTLU quando la connessione SSCP è già aperta.

    Una notifica (chiave vettoriale 0x0C con byte 5 impostata su 0x01), che attualmente non può fungere da LU secondario, viene inviata nei casi seguenti:

  • Quando viene ricevuto un ACTLU quando la connessione SSCP non è aperta.

  • Quando viene ricevuta una richiesta close(SSCP) quando la sessione PLU non è associata.

  • Quando viene ricevuta una richiesta UNBIND quando la connessione SSCP non è aperta.

  • Quando viene usata la risposta lunga che include il vettore NOTIFY per le richieste ACTLU.

    Questi messaggi NOTIFY possono essere usati dall'host in combinazione con la risposta negativa 0x0845 che il nodo locale fornisce a un bind ricevuto quando la connessione SSCP non è aperta. Per altre informazioni, vedere Apertura della connessione PLU.