Caractéristiques d’une session SSCP
Pour les nœuds de type SNA 2.1, la session du point de contrôle des services système (SSCP) utilise le profil de gestion des fonctions (FM) 0 et le profil de service de transmission (profil TS) 1. Cette combinaison de profils fournit les caractéristiques de session suivantes :
Les demi-sessions primaires et secondaires utilisent tous deux le mode de requête immédiate.
Les demi-sessions primaires et secondaires utilisent le mode de réponse immédiate.
Seules les chaînes d’unités de requête uniques à réponse définie sont autorisées.
La taille maximale de l’unité de requête est limitée à 256 octets.
Les unités de demande de contrôle de flux de données ne sont pas prises en charge.
Le rythme n’est pas pris en charge.
Des identificateurs sont utilisés (plutôt que des numéros de séquence) sur les flux normaux.
Cela implique que la connexion SSCP présente les caractéristiques suivantes :
Tous les messages de données ont le champ accusé de réception obligatoire (ACKRQD) défini.
Tous les messages de données ont les indicateurs d’application de l’indicateur de début de chaîne (BCI) et de l’indicateur de chaîne d’extrémité (ECI) définis.
Les messages Status-Control ne circulent pas sur la connexion.
Les messages d’état de session du nœud local vers l’application signalent uniquement les modifications apportées à l’état d’activation de la session.
Les protocoles de chaînage, de crochet, de confirmation et de récupération (décrits dans Connexion PLU) ne s’appliquent pas.
À l’aide de la connexion SSCP, l’application peut envoyer et recevoir des messages de données correspondant aux demandes de services de réseau de données de gestion des fonctions (FMD NS) (services de session) et aux demandes de données FMD. Voici quelques exemples de requêtes FMD NS (services de session) :
INIT-SELF. Demandes du SSCP secondaire vers le SSCP hôte demandant que le SSCP aide à initier une session au PLU hôte, en demandant effectivement une liaison. (Pour plus d’informations, consultez Ouverture de la connexion PLU.)
TERM-SELF. Demandes du SSCP secondaire à l’hôte demandant que la session PLU-SLU soit terminée par un UNBIND. (Pour plus d’informations, consultez Fermeture de la connexion PLU.)
Requêtes codées par des caractères. Les demandes telles que les commandes d’ouverture de session, de déconnexion ou de test à partir de l’affichage secondaire, ou une invite d’ouverture de session de l’application hôte.
PRÉVENIR. Demandes utilisées par le serveur secondaire pour informer le SSCP hôte qu’un appareil est disponible après qu’un bind a été rejeté avec du code d’sens 0x0845, par exemple, où un émulateur d’appareil prend en charge la mise hors tension logique.
Le nœud local envoie une demande NOTIFY au SSCP pour le compte de l’unité logique chaque fois que l’état de connexion SSCP de l’application change alors que la lu est active. Une NOTIFICATION (clé vectorielle 0x0C avec octet 5 défini sur 0x03), qui peut agir comme lu secondaire, est envoyée dans les cas suivants :
Lorsqu’une requête Open(SSCP) est reçue lorsque la lu est déjà active.
Lorsqu’une demande ACTLU est acceptée lorsque la connexion SSCP est déjà ouverte.
Une NOTIFICATION (clé vectorielle 0x0C avec octet 5 défini sur 0x01), qui ne peut actuellement pas faire office de lu secondaire, est envoyée dans les cas suivants :
Lorsqu’un ACTLU est reçu lorsque la connexion SSCP n’est pas ouverte.
Lorsqu’une demande de fermeture (SSCP) est reçue lorsque la session PLU n’est pas liée.
Lorsqu’une requête UNBIND est reçue lorsque la connexion SSCP n’est pas ouverte.
Lorsque la réponse longue incluant le vecteur NOTIFY est utilisée pour les requêtes ACTLU.
Ces messages NOTIFY peuvent être utilisés par l’hôte conjointement avec la réponse négative 0x0845 que le nœud local donne à un BIND reçu lorsque la connexion SSCP n’est pas ouverte. (Pour plus d’informations, consultez Ouverture de la connexion PLU.)