Rôle
Gérer le dialogue entre les entités applicatives.
Nous avons vu, précédemment, que la couche 4 permettait de gérer le contrôle de connexion entre process applicatifs. La couche session a le rôle plus ambigu, d’organiser le dialogue. C’est en quelque sorte le chef d’orchestre d’une relation entre processus applicatifs. Elle va regrouper des tâches, s’assurer qu’elles sont réalisées en posant des jalons dans la transmission, elle assurera enfin le partage équitable de la parole ! Démocratique la couche 5 ! C’est sans doute pour cela qu’on ne la trouve que très rarement implémentée dans les architectures informatiques !
En effet, ses fonctions sont tellement proches des préoccupations informatiques (applicatives), qu’elles sont bien souvent prises en charge par l’application elle-même, et donc difficilement discernable comme entité propre ! Ainsi l’architecture TCP-IP ne comporte pas d’équivalent de couche 5 !
L’unité de donnée du protocole est appelée la SPDU (Session Protocol Data Unit). Cette SPDU est encapsulée dans la TPDU du niveau 4.
Fonctions
1 – Gestion du dialogue
Je vous disais que la couche 5 était assez rarement implémentée, c’est bien le cas ! Surtout à l’assemblée nationale ! Pourtant la fonction de gestion du dialogue y serait bien utile. Cette fonction a pour rôle de gérer l’attribution de la parole à chaque entité applicative à tour de rôle par délivrance d’un jeton. Seule l’entité applicative possédant le jeton a le droit de prendre l’initiative d’un travail. Pas comme chez nos députés qui se jettent à coeur joie dans des débats aussi tonitruants et impétueux qu’inorganisés et séniles ! Je plaisante … Je les adore !!
La transmission du jeton pourra se faire selon le cas sur des critères de durée de parole (le plus courant), de séquencement d’opérations, voir de volume de transaction (très rare !).
2 – La synchronisation du dialogue.
Imaginez votre déconfiture lorsqu’un transfert de 10 Mo est sur le point de se terminer et qu’une coupure réseau, que n’a pas pu rattraper la couche 4, vient interrompre le travail en cours ! Une heure de boulot, à l’eau ! (Je hais les Télécoms !! Quand nous livreront-ils des liens parfaits ?). Si vous avez déjà réalisé des tranferts FTP sur Internet il y a quelques années, vous savez de quoi je parle, n’est-ce pas ?
Heureusement, une évolution du protocole FTP a permis de reprendre un téléchargement à l’endroit où il a été interrompu. Il n’est plus nécessaire de le reprendre au début. Mais à l’époque, il était normal (ou presque !) que nous perdions tout le téléchargemenent en cas de coupure réseau, car TCP-IP n’a pas de couche session !! Avec une vrai couche session de chez SESSION & Co, il y aurait eu un jalonnement du transfert de fichier en instaurant des points de reprises.
Tous les 2 Mo par exemple, l’émetteur se serait arrêté et se serait assuré auprès du destinataire de la bonne réception. Si dans un train de 2 Mo il y avait un problème, la couche session aurait lancé une reprise à partir des derniers 2 Mo validés ! En non depuis le début !!
Remarque : Actuellement, FTP simule ce principe en mémorisant le nombre d’octets téléchargés. Il conserve cette information en cache sur votre disque dur, en l’associant à l’URL du fichier téléchargé. De cette manière vous pouvez même reprendre votre téléchargement plusieurs jours après. Si l’information n’a pas été écrasée en cache, FTP va simuler un téléchargement des premiers octets déjà chargé et attaquera le réel téléchargement à l’endroit où il a été interrompu.
3 – L’organisation du dialogue.
Une relation à distance (on fait de la téléinformatique ici, Monsieur ! On travaille à distance, pas à deux mètres de son ordinateur !), entre applications peut revêtir de nombreuses formes. Les opérations peuvent être de la saisie de données dans des masques, un lancement d’impression, une sauvegarde sur disque, etc…
Pire ! Une relation entre entités applicatives peut cumuler plusieurs de ces tâches consécutivement ! Voir même simultanément ! La couche session va donc organiser sur la connexion de couche 4, la séparation en activités qui seront généralement séquencées dans le temps. Ainsi on commencera peut-être par une saisie dans un masque, suivie d’une impression du résultat sur un imprimante proche de l’opérateur et d’une sauvegarde des données dans la base !
Chaque activité aura donné lieu à un point de reprise majeur, qui jalonne le début et la fin d’une activité ! Sachant que le point de reprise mineur quand à lui assure la synchronisation du dialogue comme vu précédemment !
Remarques
Je vous avais prévenu ! Cette page est sommaire ! Les couches 5 à 7, sortent sérieusement du domaine purement téléinformatique ! Jusqu’à peu, elles étaient systématiquement noyées dans le code source applicatif. Petit à petit on voit beaucoup émerger la couche 7 mais les couches 5 et 6 restent encore très virtuelles !
La couche 5 ne trouve sa place que dans des architectures résolument orientées « Connexion » comme SNA d’IBM ou DNA en DecNet Phase V de DEC (Digital Equipment Corporation).