Conception

Le protocole est le langage qui permet à deux applications réseau de communiquer. Nous avons donc écrit un protocole de communication YooGoo. Si une application respecte le protocole, elle est en mesure de communiquer soit avec le client, soit avec le serveur de YooGoo. De plus, le protocole nous a permis de coder le serveur et le client indépendamment l'un de l'autre. Il suffit qu'ils respectent tous les deux le protocole pour qu'ils soient compatibles.

Lors de la conception du protocole, nous avons fait bien attention à ce que celui-ci soit "logique". Il ne faut pas qu'il y ait de fonctions incompatibles, ni de fonction double. Dans un protocole tel que le FTP et HTTP, il n'y a pas besoin de faire passer de l'information entre les clients. Ce n'est pas le cas dans Yoogoo. Chaque connexion au serveur est totalement indépendante. Comme YooGoo ressemble pour la plupart de ses fonctionnalités à l'IRC, nous nous sommes beaucoup inspiré du protocole de l'IRC (cf. RFC 1412 disponible sur www.YooGoo.com).

Principes

Nous avons fait en sorte que le protocole soit assez intuitif par le nom des fonctions et les paramètres. Le protocole n'est pas sensible à la case des caratères. Un utilisateur anglophone ne devrait pas avoir de problèmes pour comprendre le fonctionnement de Yoogoo seuleument en regardant le nom des fonctions. Nous nous sommes conformé à certaines règles qui permettent au protocole d'être logique. Par exemple, toutes les commande Commencant par CH permettent de changer un champ de son profile et les commandes commencant par CHCHAN permettent de changer un champ du profile d'un canal.

Lorsqu'une commande a besoin de renvoyer une information au client, le nom de ces fonction commence toujours par RPL_. Parfois, la commande a besoin de renvoyer plusieurs information au client (comme le resultat d'une recherche). On utilise alors une commande RPL_ pour chaque message d'information, puis, on termine avec RPL_END. Les commande commençant par RPL_END servent donc de balise de fin de transmition.

Il arrive que le serveur ait besoin d'envoyer un évènement au client. Le message est alors le même que la commande qui l'a provoqué.

Par exemple :

            Hargos -> msgChan Epita "Salut"
            Hargos <- msgChan Hargos Epita "Salut"
            Danao <- msgChan Hargos Epita "Salut"
            Zapata <- msgChan Hargos Epita "Salut"
            Folken <- msgChan Hargos Epita "Salut"

Nous avons hésité au début à envoyer des message plus évolué du genre "HARGOS" S'EST JOIN AU CANAL "EPITA". Ce genre de message offrait l'avantage d'être plus compréhensible pour l'utilisateur. Mais, le message aurait été plus difficile à parser pour le client. De plus, le message aurait été dans une seule langue et nous aurions eu des problèmes pour le traduire.

Retours d'erreurs

Pour chaque fonction un code d'erreur est renvoyé au client. Pour chaque commande envoyées, il y a un unique message d'erreur. Tant que le client n'a pas recu ce code, la commande est en cours d'execution. La valeur 00 signifie que tout s'est bien passé. Tous les codes 100 signifient que ce ne sont pas des erreurs fatales. Les erreurs comprises entre 400 et 499 signifient que l'erreur est fatale et que la fonction s'est terminée anormalement. Dans le protocole, les codes 100 commencent par INF_ et les code d'erreurs commence par ERR_. Ces codes d'erreur sont important car ils seront aussi utilisés en interne dans le serveur. Nous avons décidé de ne pas renvoyer d'erreur de la part du client. Effectivement, nous pensons qu'il n'est pas utile au serveur de savoir si la donnée est bien reconnue (il ne peut rien y faire s'il y a une erreur...). De plus, les messages envoyés par le serveur sont souvent des messages d'informations, il y a donc que très peu d'erreur possible. Je rappelle que TCP/IP possède un code de correction d'erreur et qu'une donnée arrive forcement à destination sans erreurs.