RFC0727 Option Telnet Logout Crispin
Groupe de travail Réseau Mark Crispin, MIT-AI
Request for Comments 727 27 avril 1977
NIC 40025 Traduction Claude Brière de L’Isle
Option TELNET Logout
1. Nom et code de la commande
LOGOUT 18
2. Signification de la commande
IAC WILL LOGOUT
L’envoyeur de cette commande DEMANDE la permission de déconnecter, ou confirme qu’il va déconnecter, de force, le
processus d’utilisateur de son côté.
IAC WON'T LOGOUT
L’envoyeur de cette commande REFUSE de déconnecter de force le processus d’utilisateur de son côté.
IAC DO LOGOUT
L’envoyeur de cette commande DEMANDE que le receveur déconnecte de force le processus d’utilisateur du côté du
receveur, ou confirme que le receveur a sa permission de le faire.
IAC DON'T LOGOUT
L’envoyeur de cette commande DEMANDE que le receveur ne déconnecte pas de force le processus d’utilisateur du côté
du receveur.
3. Par défaut
WON'T LOGOUT
DON'T LOGOUT
C’est à dire, pas de déconnexion forcée du processus d’utilisateur du serveur.
4. Motifs de l’option
Souvent, un processus d’utilisateur en cours peut se trouver bloqué dans un état qui ne peut pas être interrompu par des
moyens normaux. À l’inverse, le système lui-même peut se trouver encombré de telle sorte que les délais de réponse soient
intolérables. Un utilisateur (humain ou autre) va finalement se trouver à bout de frustration et prendre des mesures
drastiques pour fermer la connexion pour se libérer du processus en panne. Dans certaines situations, même la simple
opération de déconnexion peut prendre assez longtemps.
Certains systèmes traitent une clôture comme signifiant qu’ils devraient déconnecter le processus d’utilisateur qui le sous-
tend. Cependant, de nombreux hôtes "détachent" simplement le processus afin qu’une clôture accidentelle due à une erreur
d’utilisateur ou à une erreur de matériel temporaire ne cause pas la perte de tout le travail accompli sur cette tâche ; lorsque
la connexion est rétablie, l’utilisateur peut "se rattacher" à son processus. Bien que cette protection soit souvent précieuse,
si l’utilisateur abandonne complètement sur l’hôte, il peut causer la persistance de cette tâche en panne qui va continuer à
surcharger le système.
Cette option permet à un processus de faire savoir au serveur que le processus d’utilisateur du côté du serveur devrait être
forcé à déconnecter plutôt que détaché. Une utilisation secondaire de cette option pourrait être qu’un serveur donne un
avertissement d’auto-déconnexion imminente de son processus d’utilisateur due à l’inactivité.
page - 1 -
RFC0727 Option Telnet Logout Crispin
5. Description de l’option
Lorsque un utilisateur décide qu’il ne veut plus de son processus sur l’hôte serveur et décide qu’il ne veut plus attendre
jusqu’à ce que le protocole normal de déconnexion de l’hôte se soit déroulé, il envoie IAC DO LOGOUT. Le receveur de la
commande peut répondre par IAC WILL LOGOUT, auquel cas il va alors forcer la déconnexion du processus d’utilisateur
de son côté. Si il répond par IAC WON'T LOGOUT, il indique alors qu’il n’a pas déconnecté le processus d’utilisateur de
son côté, et si la connexion est rompue, le processus va très vraisemblablement se détacher.
Un utilisateur vraiment impatient qui estime qu’il doit se séparer immédiatement du serveur pourrait même envoyer un IAC
DO LOGOUT et fermer ensuite. Au pire, le serveur va seulement ignorer la demande et détacher le processus d’utilisateur.
Un serveur qui met en œuvre l’option LOGOUT devrait savoir comment terminer le processus d’utilisateur en dépit de la
brusque clôture et même de l’incapacité à confirmer la demande LOGOUT !
6. Exemple de mise en œuvre de l’option
Le serveur met en œuvre l’option LOGOUT à la fois pour accepter les demandes LOGOUT et pour l’avertissement d’auto-
déconnexion.
Cas 1 :
L’utilisateur se connecte au serveur, et commence à interagir avec le serveur. Pour une raison quelconque, l’utilisateur
souhaite terminer l’interaction avec le serveur, et il est réticent à passer par la procédure normale de déconnexion, ou peut-
être que l’utilisateur est dans l’incapacité de passer par la procédure normale de déconnexion. Il ne veut plus du processus
au serveur, de sorte qu’il envoie le IAC DO LOGOUT. Le serveur vérifie la demande avec IAC WILL LOGOUT, et ensuite
déconnecte de force le processus d’utilisateur (peut-être en utilisant un appel système qui cause la déconnexion d’un autre
processus). Il n’a pas à clore la connexion sauf si l’utilisateur la ferme ou si il veut la fermer. Il n’attend pas que l’utilisateur
ait reçu sa confirmation – il commence la déconnexion immédiatement de sorte que si dans l’intervalle, l’utilisateur a fermé
la connexion sans attendre la confirmation, sa demande de déconnexion est déjà effectuée.
Cas 2 :
L’utilisateur se connecte au serveur, et après la connexion, est inactif pendant un certain temps, assez longtemps pour
approcher du délai d’auto-déconnexion du serveur. Le serveur envoie, peu avant l’auto-déconnexion, le IAC WILL
LOGOUT ; l’utilisateur le voit et envoie un IAC DON'T LOGOUT, et continue de travailler sur l’hôte. Rien n’empêche le
serveur de déconnecter le processus d’utilisateur si l’inactivité continue ; cela peut être utilisé pour empêcher un usager
malveillant de connecter un processus sur l’hôte serveur par le simple expédient de l’envoi d’un IAC DON'T LOGOUT
chaque fois qu’il voit un IAC WILL LOGOUT mais ne fait rien d’autre.
page - 2 -
