Pour communiquer, le client et le serveur CORTINA échangent des messages contenant des données des types primitifs Java « char » et « int ». Le type « char » permet de représenter l´ensemble des caractères du code Unicode, un code 16 bits, tandis que le type « int » permet de représenter les nombres entiers signés qui peuvent être représentés sur 32 bits en complément à deux. Dans les deux cas, le mode de transmission utilisé est le mode gros-boutiste (big-endian).
Les clients qui sont implémentés sur des plateformes utilisant un autre code de caractères, par exemple un code ASCII (7 ou 8 bits), et un autre mode de transmission, par exemple le mode petit-boutiste (little-endian), doivent nécessairement procéder aux conversions de types appropriées. C´est ce que fait, en l´occurrence, notre client pour Word sous Windows.
Lorsque le client et le serveur doivent échanger une chaîne de caractères, ils transmettent d´abord le nombre de caractères composant la chaîne, sous forme d´un entier, suivi des caractères de la chaîne, du premier au dernier.
Le dialogue entre le client et le serveur passe par un certain nombre de phases qui sont détaillées dans les paragraphes suivants. Chaque phase consiste en un échange de requêtes du client et de réponses du serveur. Toutes les requêtes et réponses sont indentifiées par un entier et peuvent être suivies d´informations supplémentaires.
Cette phase doit permettre au client CORTINA de vérifier si le protocole qu´il implémente est toujours supporté. En effet, comme les clients CORTINA peuvent être téléchargés gratuitement, nous ne contrôlons pas du tout la diffusion de ces clients. Dans la mesure où, d´une part, nous souhaitons conserver toute liberté pour faire évoluer le serveur de correction CORTINA (ainsi que, de manière sousjacente, le protocole CORTINA) et, d´autre part, nous voulons éviter à l´utilisateur la surprise de se retrouver soudainement avec un client qui ne fonctionne plus sans qu´il ne sache pourquoi, le premier échange de message permet au client de savoir s´il dialogue avec un seveur qui est capable de lui répondre comme il s´y attend.
Pour vérifier la version, le client doit envoyer une requête de vérification de version au serveur suivi de la version :
La figure suivante montre le message envoyé au serveur par un client qui implémente le protocole CORTINA version 1.0 (les valeurs sont indiquées en hexadécimal) :
Le serveur peut répondre de trois manières différentes :
La réponse du serveur est composée d´un entier identifiant la réponse :
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui implémente la même version de protocole que le client :
Si le client entame le dialogue avec une autre requête que la vérification de version, le serveur répond que la requête est illégale. Dans ce cas aussi, la réponse est composée d´un entier unique identifiant la réponse :
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui refuse de traiter une requête avant d´avoir procédé à la vérification de version :
Si la version du protocole est toujours supportée par le serveur, le client peut procéder à des corrections orthographiques. Il peut utiliser le serveur de deux manières différentes :
Le mode « correction de mots isolés » est le mode le plus simple. Dans ce mode, le client envoie des mots à vérifier au serveur qui répond, pour chaque mot, s´il a retrouvé ou non le mot dans le dictionnaire et, sinon, fournit les mots du dictionnaire les plus proches des mots à vérifier. La vérification se fait indépendamment de tout contexte, c´est-à-dire des mots ou signes de ponctuation qui se trouvent à gauche ou à droite du mot à vérifier.
Pour cela, le client doit envoyer une requête de vérification de mot isolé au serveur suivie du mot à vérifier :
Les diverses requêtes permettent de limiter le nombre d´alternatives fournies par le serveur de trois façons différentes :
Il est à noter que les divers maxima sont des paramètres de fonctionnement du serveur et non pas des données transmises par le client.
La figure suivante montre le message envoyé au serveur par un client qui demande au serveur de vérifier si le mot « Moien » est correctement orthographié (les valeurs sont indiquées en hexadécimal) et de limiter à un certain maximum le nombre d´alternatives proposées en cas de non-reconnaissance (requête 11100) :
Le serveur répond à cette requête en envoyant au client un entier qui indique si le mot est un mot du dictionnaire ou non :
Dans le deuxième cas, la réponse est suivie de l´ensemble des alternatives, ensemble trié dans l´ordre décroissant des distances des alternatives au mot à vérifier.
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui l´informe que le mot qu´il devait vérifier appartient bien au dictionnaire :
La liste des alternatives, si le mot à vérifier n´appartenait pas au dictionnaire, est composée de :
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui l´informe que le mot qu´il devait vérifier n´appartient pas au dictionnaire et qu´il y a deux alternatives, les mots « Moien » et « Miel » :
Le fait que le mot ait été trouvé ou non, le nombre d´alternatives et les alternatives proposées dépendent bien sûr de l´état du dictionnaire au moment de la vérification. Actuellement, ce dernier évolue encore régulièrement.
Le mode « correction de textes » est un peu plus élaboré que le mode « correction de mots isolés », dans la mesure où on y prend en compte des informations contextuelles. Toutefois, ce contexte est fort limité et il ne s´agit pas de faire de la correction grammaticale. En effet, le serveur prend en compte le contexte uniquement pour traiter deux phénomènes :
Afin de traiter ces deux phénomènes, le serveur de correction gère un contexte de quatre mots : l´antépénultième, le précédent, le courant et le suivant. Il est à noter que la notion de mot est à prendre au sens large dans le contexte de la correction de textes. Toute séquence de caractères non blancs (les caractères blancs sont des caractères tels que l´espace, la tabulation etc.) est à prendre en considération pour la correction. Notamment, les caractères de ponctuation ont une importance capitale : un point en fin de phrase force l´utilisation de majuscules en début de phrase suivante, une virgule derrière un mot empêche l´application de la « Äifeler Regel » à ce mot et ainsi de suite. D´autres séquences de caractères non blancs qui ne sont pas des mots, par exemple les nombres, influent également sur le processus de correction. De ce fait, toutes ces séquences doivent apparaître dans le contexte même si elles ne sont pas destinés à être vérifiées. Comme on va le voir ci-dessous, le client a, par conséquent, la possiblité, dans le cadre de la correction de textes, de transmettre des mots au serveur qu´il souhaite uniquement inclure dans le contexte sans les faire vérifier.
La première chose à faire lorsqu´un client CORTINA souhaite faire corriger un texte consiste à initialiser le contexte. En effet, au début de l´examen d´un texte, aucun mot n´a encore été vérifié. Par conséquent, le client doit informer le serveur qu´il souhaite entamer le traitement avec un contexte vierge.
Pour cela, le client doit envoyer une requête d´initialisation de contexte au serveur :
Cette requête ne nécessite aucune information supplémentaire. La figure suivante montre le message envoyé au serveur par un client qui demande au serveur d´initialiser le contexte :
La requête ne donne lieu à aucune réponse de la part du serveur.
Durant tout le processus de correction, le client doit mettre à jour le contexte. Comme indiqué précédemment, ce dernier se compose de quatre mots (mots au sens large décrit ci-dessus) et se comporte comme une file à quatre positions. Lorsqu´on ajoute un mot au contexte, l´antépénultième (le premier dans la file) est perdu, les autres avancent d´une position et le mot ajouté devient le mot suivant (le dernier dans la file).
Diverses requêtes permettent au client de mettre à jour le contexte.
Une première requête permet d´ajouter un mot qui sera à vérifier :
Une deuxième requête permet d´ajouter une fin de phrase :
Une troisième requête permet d´ajouter un séparateur (par exemple une virgule ou une séquence de lettres et chiffres etc.) :
Une dernière requête permet d´informer le serveur que le client est arrivé à la fin du texte à corriger :
Cette dernière requête ne nécessite pas d´information supplémentaire.
La figure suivante montre le message envoyé au serveur par un client qui demande au serveur d´ajouter le mot « Moien » au contexte (requête 13000, les valeurs sont indiquées en hexadécimal) :
Aucune des requêtes de mise à jour du contexte ne donne lieu à une réponse de la part du serveur.
A tout moment, le client peut demander au serveur de vérifier l´orthographe du mot courant dans le contexte. Ce dernier vérifie alors le mot courant et indique ensuite au client si le mot appartient au dictionnaire ou non. S´il n´y appartient pas, le serveur fournit en plus les mots les plus proches du mot à vérifier. La vérification et la proposition d´alternatives se font ici dans le contexte, à savoir : en tenant compte des débuts de phrase et de la « Eifeler Regel ».
Pour faire vérifier le mot courant du contexte, le client doit envoyer une requête de vérification du mot courant au serveur, requête contenant :
Les diverses requêtes permettent de limiter le nombre d´alternatives fournies par le serveur de trois façons différentes :
Rappelons que les divers maxima sont des paramètres de fonctionnement du serveur et non pas des données transmises par le client.
La figure suivante montre le message envoyé au serveur par un client qui demande au serveur de vérifier si le mot courant du contexte est correctement orthographié et de limiter à un certain maximum le nombre d´alternatives proposées en cas de non-reconnaissance (requête 14100) :
Le serveur répond à ces requêtes en envoyant au client un entier qui indique si le mot courant du contexte est un mot du dictionnaire ou non et respecte les contraintes contextuelles :
Dans le deuxième cas, la réponse est suivie de l´ensemble des alternatives, ensemble trié dans l´ordre décroissant des distances des alternatives au mot courant.
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui l´informe que le mot qu´il devait vérifier appartient bien au dictionnaire et respecte les contraintes contextuelles :
La liste des alternatives, si le mot à vérifier n´appartenait pas au dictionnaire, est composée de :
La figure suivante montre le message (en hexadécimal) envoyé au client par un serveur qui l´informe que le mot qu´il devait vérifier n´appartient pas au dictionnaire ou ne respecte pas les contraintes contextuelles et qu´il y a deux alternatives, les mots « Moien » et « Miel » :
Rappelons que le fait que le mot ait été trouvé ou non, le nombre d´alternatives et les alternatives proposées dépendent bien sûr de l´état du dictionnaire au moment de la vérification. Actuellement, ce dernier évolue encore régulièrement.
Une fois que le client a terminé de faire corriger un texte, il signale au serveur que le contexte peut être effacé. La connection avec le serveur reste établie mais si le client souhaite à nouveau faire corriger un texte, il doit d´abord initialiser le contexte.
Pour signaler au serveur que ce dernier peut effacer le contexte, le client fait parvenir une requête de clôture de contexte au serveur :
La figure suivante montre le message envoyé au serveur par un client qui demande au serveur de d´effacer le contexte :
La requête ne donne lieu à aucune réponse de la part du serveur.
Lorsque le client ne souhaite plus faire vérifier de mots, il peut clore la communication avec le serveur.
Avant de clore la communication, il peut informer le serveur de son intention en lui faisant parvenir une requête de terminaison de communication :
La figure suivante montre le message envoyé au serveur par un client qui demande au serveur de clore la communication.
La requête ne donne lieu à aucune réponse de la part du serveur.