Le contr�le de flux (= prise de contact (handshaking) = ralentissement) permet d'emp�cher un flux d'octets trop rapide de d�passer un terminal, un ordinateur, un modem ou un autre p�riph�rique. Le d�passement est le fait qu'un p�riph�rique ne puisse pas traiter ce qu'il re�oit assez rapidement et ainsi perd des octets et/ou fait d'autres erreurs s�rieuses. Ce que fait le contr�le de flux est d'arr�ter le flux d'octets jusqu'� ce que le terminal (par exemple) soit pr�t � recevoir des octets suppl�mentaires. Le contr�le de flux envoie un signal pour arr�ter le flux dans la direction oppos�e au flux des donn�es qu'il veut arr�ter. Le contr�le de flux doit �tre lanc� � la fois sur le terminal et sur l'ordinateur.
Il y a deux types de contr�le de flux : mat�riel et logiciel (Xon/Xoff ou DC1/DC3). Le contr�le de flux mat�riel utilise des fils de signaux d�di�s comme RTS/CTS ou DTR/DSR alors que le contr�le de flux logiciel se signale en envoyant les octets de contr�le DC1 ou DC3 dans les fils de donn�es normaux. Pour le contr�le de flux mat�riel, le c�ble doit �tre c�bl� correctement.
Le flux des octets de donn�es dans le c�ble entre deux ports s�rie est bidirectionnel, il y a donc deux flux (et deux fils) diff�rents � consid�rer :
Vous pouvez vous demander : "Pourquoi ne pas envoyer les donn�es � une vitesse suffisamment petite pour que le p�riph�rique ne soit pas d�pass� et que le contr�le de flux ne soit ainsi plus n�cessaire ?" Ceci est possible mais c'est en g�n�ral bien plus lent que d'envoyer les donn�es plus rapidement et d'utiliser le contr�le de flux. Une raison � ceci est qu'on ne peut pas positionner la vitesse du port s�rie � n'importe quelle vitesse comme 14.500, puisqu'un nombre limit� de choix est disponible. Le meilleur choix est de s�lectionner une vitesse l�g�rement plus �lev�e que ce que peut soutenir le p�riph�rique et d'utiliser ensuite le contr�le de flux pour que les choses fonctionnent correctement.
Si on d�cide de ne pas utiliser le contr�le de flux, la vitesse doit alors �tre suffisamment basse pour pallier � la pire des situations. Pour un terminal, cela arrive quand on envoie des s�quences d'�chappement pour effectuer des t�ches complexes qui prennent plus de temps qu'� l'accoutum�e. Dans le cas d'un modem (avec la compression de donn�es mais pas de contr�le de flux) la vitesse de l'ordinateur au modem doit �tre suffisamment basse pour que cette m�me vitesse soit utilisable sur la ligne t�l�phonique, puisque dans le pire des cas les donn�es sont al�atoires et ne peuvent �tre compress�es. Si on ne pouvait pas utiliser de contr�le de flux, la vitesse (avec la compression de donn�es activ�e) ne serait pas plus rapide que si on n'utilisait pas de compression du tout.
Les buffers (m�moires tampons) aident � g�rer les situations catastrophes de courte dur�e. Le tampon stocke les octets qui arrivent trop rapidement pour �tre trait�s tout d'un coup, et les garde pour les traiter plus tard.
Une autre mani�re de g�rer une situation "catastrophe" (sans utiliser de contr�le de flux ni de tampon) est d'ajouter un groupe de nulls (octets de valeur z�ro) aux s�quences d'�chappement. Quelquefois on utilise des DEL � la place, � condition qu'ils n'aient pas d'autre fonction. Voyez reconna�tre DEL.
La s�quence d'�chappement permet au terminal de commencer � faire quelque
chose, et pendant que le terminal est occup� � le faire, il re�oit une
poign�e de nulls qu'il ignore. Quand il re�oit le dernier null, il a termin�
sa t�che et est pr�t pour la commande suivante. C'est ce qu'on appelle le
remplissage de z�ros (null padding). Ces nulls �taient autrefois appel�s des
"caract�res de remplissage". Ces nulls sont ajout�s simplement pour "perdre"
du temps, mais ce n'est pas tout � fait perdu puisque le terminal est en
g�n�ral occup� � faire autre chose pendant que les nulls sont re�us. On
utilisait beaucoup cette m�thode dans le pass� avant que le contr�le de flux
ne devienne populaire. Pour �tre efficace, il fallait ajouter le nombre exact
de nulls et trouver la bonne valeur est difficile. On le faisait souvent par
essais successifs et t�tonnements puisque les manuels de terminaux n'�taient
pas de grand secours. Si le contr�le de flux ne fonctionne pas correctement
ou n'est pas impl�ment�, le remplissage est une solution. Certaines options
de la commande stty concernent le remplissage.
On peut se demander comment le d�bordement est possible sur un port s�rie puisqu'� la fois les ports s�rie d'envoi et de r�ception servant � la transmission d'octets de donn�es sont param�tr�s pour la m�me vitesse (en bits/s) comme 19200. La raison est que bien que l'�lectronique du port s�rie r�cepteur peut g�rer la vitesse du flux arrivant, le mat�riel/logiciel qui prend et traite les octets du port s�rie ne peut pas toujours se d�brouiller avec une vitesse de flux �lev�e.
L'une des causes de ceci est que le tampon mat�riel du port s�rie est assez petit. Les anciens ports s�rie avaient une taille de tampon mat�riel d'un octet seulement (� l'int�rieur de la puce UART). Si cet unique octet de donn�es re�u dans le tampon n'est pas enlev� (pris) par des instructions CPU avant que l'octet suivant n'arrive, cet octet est perdu (le tampon est d�bord�). Les UART r�cents, par exemple la plupart des 16550A, poss�dent des tampons de 16 octets (mais peuvent �tre param�tr�s pour �muler un tampon d'un octet) et sont moins susceptibles d'�tre d�bord�s. On peut le param�trer pour envoyer une interruption quand le nombre d'octets dans son tampon atteint 1, 4, 8 ou 14 octets. C'est le travail d'une autre puce dans l'ordinateur (g�n�ralement la puce principale CPU pour un ordinateur) de retirer ces octets entrants de ce petit tampon mat�riel et de les traiter (ainsi que d'effectuer d'autres t�ches).
Quand le contenu de ce petit tampon mat�riel de r�ception atteint la limite sp�cifi�e (un octet pour les vieux UART) une interruption est lev�e. L'ordinateur interrompt alors ce qu'il �tait en train de faire et une routine fait une v�rification pour d�terminer ce qui vient de se passer. Il d�termine finalement qu'il doit retirer un octet (ou plusieurs) du tampon du port s�rie. Il prend cet (ces) octet(s) et les met dans un tampon plus grand (un autre tampon pour le port s�rie) que le noyau maintient dans la m�moire principale. Pour le tampon de transmission, le mat�riel s�rie g�n�re une interruption quand le tampon est vide (ou presque vide) pour dire � la CPU de mettre quelques octets suppl�mentaires dans ce tampon afin de les envoyer.
Les terminaux poss�dent aussi des ports s�rie et des tampons similaires � ceux de l'ordinateur. Puisque le flux de donn�es des octets vers le terminal est en g�n�ral plus grand que le flux dans la direction oppos�e du clavier vers l'ordinateur h�te, le terminal a plus de chance de souffrir du d�bordement. Bien s�r, si vous utilisez un ordinateur comme terminal (par �mulation), il est � son tour sujet au d�bordement.
Les situations risqu�es o� le d�bordement est tr�s probable sont : 1. quand un autre processus a d�sactiv� les interruptions (pour un ordinateur), 2. quand le tampon du port s�rie dans la m�moire principale (ou dans celle du terminal) est pr�te � d�border.
Quand le r�cepteur est sur le point d'�tre d�bord� par les octets entrants, il envoie un signal � l'exp�diteur pour arr�ter l'envoi. C'est le contr�le de flux et les signaux de contr�le de flux sont toujours envoy�s dans la direction oppos�e au flux de donn�es qu'ils contr�lent (bien que ce ne soit pas dans le m�me canal ou le m�me fil). Ce signal peut �tre soit un caract�re de contr�le (^S = DC3 = Xoff) envoy� comme un octet de donn�es ordinaire sur la ligne de donn�es (signalement dans la bande), soit une transition de tension du positif au n�gatif dans le fil de signal dtr-vers-cts (ou autre ; signalement hors-bande). L'utilisation de Xoff est appel�e "contr�le de flux logiciel" et l'utilisation du saut de tension dans un fil de signal d�di� (� l'int�rieur du c�ble) est appel�e contr�le de flux mat�riel.
Avec les terminaux, le cas le plus commun "d'arret d'envoi", est quand le terminal ne peut pas suivre avec les caract�res qui lui sont envoy�s et qui en conclut par un "arret" du PC. Un autre cas, est quand quelqu'un presse control-S. Un autre cas un peu moin commun, est l'oppos�, quand le PC ne peut plus suivre votre vitesse de frappe et dit au terminal d'arr�ter l'envoi. Le terminal "bloque" le clavier et un message ou une lumi�re devrait vous informer que le clavier est bloqu�. Tout ce que vous tapez sur un clavier bloqu� est ignor�.
Le terme "bloqu�" est aussi quelque fois utilis� pous les cas o� l'on dit � l'ordinateur d'arr�ter d'envoyer � un terminal. Le clavier n'est pas bloqu�, afin que tout ce que vous tapez soit envoy� � l'ordinateur, mais puisque l'ordinateur ne peut rien vous renvoyer, les caract�res que vous tapez ne s'affichent pas sur l'�cran et il peut sembler que le clavier est bloqu�. Le d�filement est bloqu� (scroll lock) mais le clavier n'y est pas.
Quand le r�cepteur a rattrap� son retard dans le traitement et est pr�t � recevoir plus d'octets de donn�es il envoie un signal � l'envoyeur. Pour le contr�le de flux logiciel ce signal est le caract�re de contr�le ^Q = DC1 = Xon qui est envoy� sur la ligne de donn�es normale. Pour le contr�le de flux mat�riel la tension dans une ligne de signal passe de n�gative (ni�e) � positive (affirm�e). Si on dit � un terminal de reprendre la transmission le clavier est alors d�bloqu� et pr�t � �tre utilis�.
Certains terminaux anciens n'offrent pas de contr�le de flux mat�riel alors que d'autres offraient un assortiment vari� de broches diverses sur le port s�rie pour le faire. Pour une liste des differentes borches, aller voir Brochage standard d'un cable null-modem. La broche la plus en vogue actuellement semble �tre la broche DTR (ou les broches DTR et DSR ensemble).
Les PC Linux utilisent RTS/CTS mais le contr�le de flux DTR/DSR (utilis� par certains terminaux) se comporte de la m�me mani�re. Le contr�le de flux DTR (dans une seule direction et aussi utilis� par certains terminaux) n'est que la partie DTR du contr�le de flux DTR/DSR.
RTS/CTS utilise les broches RTS et CTS sur le connecteur s�rie (EIA-232). RTS veut dire "Request To Send" (demande d'envoyer). Quand cette broche reste en position haute (tension positive) sur le r�cepteur cela veut dire : continuez de m'envoyer des donn�es. Si RTS passe en position basse (la tension devient n�gative), cela nie "demande d'envoyer", ce qui veut dire : arr�tez d'envoyer. Quand le r�cepteur est pr�t � recevoir plus de donn�es, il relance RTS, demandant � l'autre c�t� de reprendre l'envoi. Pour les ordinateurs et les terminaux (tous les deux des �quipements terminaux) la broche RTS envoie le signal de contr�le de flux � la broche CTS (Clear To Send, pr�t � envoyer) de l'autre c�t� du c�ble. C'est-�-dire que la broche RTS � un bout du c�ble est reli�e � la broche CTS � l'autre bout du c�ble.
Pour un modem (�quipement de connexion) le principe est diff�rent puisque la broche RTS du modem re�oit le signal et sa broche CTS l'envoie. Alors que ceci peut sembler d�routant, il y a des raisons historiques correctes pour l'expliquer, raisons qui sont trop compliqu�es pour en discuter ici.
Les terminaux disposent en g�n�ral du contr�le de flux DTR ou DTR/DSR. Le contr�le de flux DTR est le m�me que le contr�le de flux DTR/DSR mais il est unidirectionnel et la broche DSR n'est pas utilis�e. En ce qui concerne le contr�le de flux DTR/DSR sur un terminal, le signal DTR est comme le signal envoy� de la broche RTS, et la broche DSR est simplement comme la broche CTS.
Certains terminaux n'utilisent que le contr�le de flux DTR. C'est un contr�le de flux unidirectionnel uniquement pour emp�cher le terminal d'�tre d�pass�. Il ne prot�ge pas l'ordinateur de quelqu'un qui tape trop vite pour que l'ordinateur puisse g�rer la situation. Dans un c�ble null modem classique la broche DTR du terminal est reli�e � la broche DSR de l'ordinateur. Linux, par contre, ne supporte pas le contr�le de flux DTR/DSR (bien que des pilotes pour des cartes multiports peuvent supporter le contr�le de flux DTR/DSR). Un moyen de contourner ce probl�me est simplement de relier la broche DTR � la broche CTS sur l'ordinateur et d'activer le contr�le de flux RTS/CTS (stty crtscts). Le fait que ce soit unidirectionnel ne changera rien tant que l'h�te n'est pas d�pass� par votre vitesse de frappe et ne l�che RTS en une vaine tentative pour bloquer votre clavier. Voyez blocage du clavier. Pour obtenir le contr�le de flux DTR/DSR (si votre terminal supporte ce type de contr�le de flux bidirectionnel) vous faites ce qui est d�crit ci-dessus. Mais vous connectez aussi la broche DSR sur le terminal � la broche RTS sur l'ordinateur. Vous �tes alors prot�g� si vous tapez trop rapidement.
Ce qui est d�routant est que l'utilisation d'origine de RTS veut dire � peu pr�s le contraire de l'explication pr�c�dente ci-dessus. La signification d'origine est : je demande � vous envoyer (I Request To Send to you). Cette requ�te �tait destin�e � �tre envoy�e d'un terminal (ou d'un ordinateur) vers un modem qui, s'il d�cidait d'accorder la requ�te, renvoyait un CTS affirmatif � partir de sa broche CTS vers la broche CTS de l'ordinateur : vous �tes autoris� � m'envoyer (You are Cleared To Send to me). Notez qu'au contraire du contr�le de flux RTS/CTS bidirectionnel du modem, ceci ne prot�ge le flux que dans une direction : de l'ordinateur (ou du terminal) vers le modem.
Pour de vieux terminaux, RTS peut avoir cette signification et devient positif quand le terminal doit envoyer des donn�es. L'utilisation ci-dessus est une forme de contr�le de flux puisque si le modem veut que l'ordinateur arr�te d'envoyer il l�che CTS (connect� au CTS de l'ordinateur) et l'ordinateur arr�te d'envoyer.
Les vieux terminaux � sortie papier peuvent avoir une broche de canal invers� (comme la broche 19) qui se comporte comme la broche RTS dans le contr�le de flux RTS/CTS. Cette broche passera aussi en n�gatif s'il n'y a plus de papier ou de ruban. Il est souvent possible de relier cette broche � la broche CTS de l'ordinateur h�te. Il peut y avoir un petit interrupteur pour positionner la polarit� de ce signal.
Certains pensent que le contr�le de flux mat�riel est fait par le mat�riel mais (sauf si vous utilisez une carte s�rie intelligente avec plusieurs ports s�rie) c'est en r�alit� votre syst�me d'exploitation qui s'en charge. Les puces UART et le mat�riel associ� ne connaissent en g�n�ral rien du contr�le de flux mat�riel. Quand un signal de contr�le de flux mat�riel est re�u, le fil du signal inverse la polarit�. Ce changement d'�tat est enregistr� dans un registre de port s�rie qui est v�rifi� par le pilote s�rie avant de mettre les octets dans les tampons materiels de 16 octets. Si le fil du control de flux dit "stop", il n'y a plus d'octets ajout�s et le flux sortant des lignes s�ries s'arrete.
Il y'a un autre moyen qui aurait pu �tre implementer depuis que la polarit� s'inverse, le materiel aurait pu �tre configur� pour envoyer un signal �l�ctrique d'interruption au processeur. Alors le processeur arreterait ce qu'il �tait en train de faire, se brancherait a un sous-programme de service du pilote s�rie, verifierait les registres dans lesquels le port serie a laiss� des traces pour trouver ce qui s'est pass�, et fais un rapport, pour ne pas red�marrer le flux apres que le sous programme de service soit quitt�. Cela doit �tre un peu plus efficace, mais il semble que Linux n'agisse pas comme ca. A mon avis.
Noter qu'avec l'une ou l'autre des methodes, le flux d'octets s'arrette quasiment instantanement. Cependant tous les octets (jusqu'� 16) qui �taient d�j� dans le tampon de transmission mat�riel du port s�rie seront encore transmis. Utiliser un control de flux logiciel requiert que chaque octet arrivant soit verifi� pour voir si c'est un octet "eteint". Ces octets sont retard�s en passant � travers le tampon de r�ception de 16 octets. Si l'octet "�teint" �tait le premier octet dans ce tampon, il pourrait y avoir une attente le temps que 15 octets soient re�us. Alors les 16 octets lus seraient obtenus et l'octet "�teint" trouv�. Cette attente supplementaire n'arrive pas avec un control de flux materiel.
Ceci est aussi du contr�le de flux mat�riel et n�cessite un pilote de p�riph�rique qui sait le traiter. Les octets sont envoy�s par paquets (gr�ce au port s�rie asynchrone), chaque paquet �tant termin� par un caract�re de contr�le ETX (End of Text, fin de texte). Quand le terminal re�oit un ETX il attend jusqu'� ce qu'il soit pr�t � recevoir le paquet suivant et retourne alors un ACK (Acknowledge, acquittement). Quand l'ordinateur re�oit le ACK, il envoie le paquet suivant. Et ainsi de suite. Ceci n'est pas support� par Linux ?? Certains terminaux HP utilisent la m�me m�thode mais utilisent ENQ au lieux de ETX.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:43