DP Tool Club 22

home *** CD-ROM | disk | FTP | other *** search

/ DP Tool Club 22 / CD_ASCQ_22_0695.iso / win / fr / doc12 / scoop.mm_ / scoop.mm

Wrap

Text File | 1994-12-16 | 35KB | 695 lines

liaison_glossaire liaison_bibliographie fermer_fichier_lier 0 branche type_branche 0 l_index 0 nom_branche SCOOP.MMO full_path SCOOP.MMO niveau_branche 1 mots_cles 1 - Extraits du mΘmoire de maitrise 1992|2 - Auteurs:|3 - Bertrand LE QUELLEC|4 - et Fabien DENIS branche type_branche 0 l_index 1 nom_branche HIERARCHIE DES CLASSES full_path SCOOP.MMO\HIERARCHIE DES CLASSES niveau_branche 2 mots_cles branche type_branche 0 l_index 2 nom_branche Root full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root niveau_branche 3 mots_cles branche type_branche 1 l_index 3 nom_branche Scoop full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop niveau_branche 4 mots_cles METHODES VIRTUELLES:|Push|Pop|Demux|Init|Open|OpenEnable|Close|InstantiateProtl branche type_branche 0 l_index 4 nom_branche User full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\User niveau_branche 5 mots_cles branche type_branche 0 l_index 5 nom_branche UDPaddr full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\UDPaddr niveau_branche 5 mots_cles branche type_branche 0 l_index 6 nom_branche IPaddr full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\IPaddr niveau_branche 5 mots_cles branche type_branche 0 l_index 7 nom_branche ICMPaddr full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\ICMPaddr niveau_branche 5 mots_cles branche type_branche 0 l_index 8 nom_branche ARPaddr full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\ARPaddr niveau_branche 5 mots_cles branche type_branche 0 l_index 9 nom_branche ETHaddr full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\ETHaddr niveau_branche 5 mots_cles branche type_branche 1 l_index 10 nom_branche Tache full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\Tache niveau_branche 5 mots_cles METHODES:|Create|Pid|GetPriorite|Display branche type_branche 1 l_index 11 nom_branche ListeTache full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\Tache\ListeTache niveau_branche 6 mots_cles METHODES:|DelListe|AddListe|InsListe|AddTache|DelTache|FindTache|GetQueue|GetTete|InitTete|InitQueue|AddObjListe|InsObjListe branche type_branche 0 l_index 12 nom_branche Scheduler full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Scoop\Tache\ListeTache\Scheduler niveau_branche 7 mots_cles METHODES:|Put|Get|Exec branche type_branche 0 l_index 13 nom_branche NMsg full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\NMsg niveau_branche 4 mots_cles branche type_branche 0 l_index 14 nom_branche Msg full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\NMsg\Msg niveau_branche 5 mots_cles METHODES:|MsgPush|MsgPop|MsgLen|MsgLen|MsgJoin|MsgBreak|MsgFree|MsgSave|MsgMakeAllStack branche type_branche 0 l_index 15 nom_branche Map full_path SCOOP.MMO\HIERARCHIE DES CLASSES\Root\Map niveau_branche 4 mots_cles METHODES:|MapCreate|MapBind|MapResolve branche type_branche 2 l_index 26 nom_branche 1 - INTRODUCTION full_path SCOOP.MMO\1 - INTRODUCTION niveau_branche 2 mots_cles l_auteur la_reference [Stroustrup 86] [Hansen 90] [Colnet 90] [Campbell 88] [Bach 89] [AFNOR] la_description S.C.O.O.P., SystΦme de Communication OrientΘ Objet pour Protocoles est un simulateur fonctionnant au dessus d'Unix. Il reprend dans ses grandes lignes les fonctionnalitΘs du simulateur x-Kernel. La principale propriΘtΘ de SCOOP est qu'il est entiΦrement conτu dans un langage orientΘ objet : le C++. Certaines fonctionnalitΘs de x-Kernel ont ΘtΘ assouplies ou supprimΘes (gestion de la mΘmoire, gestionnaire dÆΘvΘnements, gestion des processus), le but Θtant de montrer une implΘmentation dans un langage orientΘ objet de la composante principale de x-Kernel : son gestionnaire de communication, α la base a ΘtΘ conτu en langage C. SCOOP simule les diffΘrentes couches rΘseau (UDP, IP, ARP, ICMP) le driver ethernet Θtant en fait l'ouverture d'une socket. Nous avons conservΘ la modularitΘ d'x-Kernel, et donc la possibilitΘ d'implΘmenter facilement un nouveau protocole. branche type_branche 2 l_index 27 nom_branche 2 - CHOIX DE D╔VELOPPEMENT full_path SCOOP.MMO\2 - CHOIX DE D╔VELOPPEMENT niveau_branche 2 mots_cles l_auteur la_reference la_description SCOOP a ΘtΘ dΘveloppΘ en C++ avec le compilateur GNU (g++, version 1.40) sur des stations de travail SONY News. AprΦs l'Θtude du systΦme d'exploitation Choices et de x-Kernel il nous a semblΘ que le langage C++ est le plus adaptΘ pour l'Θlaboration de SCOOP. De plus, notre connaissance du langage C, nous permettait sans doute un passage plus rapide vers le C++ que vers un autre langage orientΘ objet. Bien que x-Kernel ait ΘtΘ pensΘ dans un style orientΘ objet, il a fallu Θtudier un nouveau fonctionnement pour pouvoir l'adapter au C++ tout en gardant sa philosophie. Notre premier travail a ΘtΘ de dΘfinir les classes d'objets ainsi que les liens d'hΘritage entre les classes. Ensuite nous avons Θcrit tout le code en C++, parfois nous n'avons fait qu'une simple transposition. Mais le C++ Θtant beaucoup moins permissif que le langage C, nous avons souvent rΘΘcrit le code d'une autre maniΦre en pensant en terme d'objet, et non plus en terme procΘdural comme avec le langage C. branche type_branche 2 l_index 28 nom_branche 3 - PR╔SENTATION G╔N╔RALE full_path SCOOP.MMO\3 - PR╔SENTATION G╔N╔RALE niveau_branche 2 mots_cles l_auteur la_reference la_description Le simulateur SCOOP fonctionne au dessus d'Unix et simule les diffΘrentes couches du rΘseau. Nous avons choisi un modΦle de type client-serveur pour illustrer le fonctionnement de SCOOP. SCOOP est lancΘ simultanΘment sur deux stations : une en mode client et l'autre en mode serveur. Le serveur aprΦs son initialisation (on simule le boot d'une station), est en attente d'une interruption. Le client, aprΦs lui aussi Ωtre passΘ par une phase d'initialisation, envoi une sΘrie de messages au serveur. branche type_branche 0 l_index 29 nom_branche 4 - ORGANISATION HI╔RARCHIQUE DES CLASSES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES niveau_branche 2 mots_cles branche type_branche 2 l_index 30 nom_branche 4 - ORGANISATION HI╔RARCHIQUE DES CLASSES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES niveau_branche 3 mots_cles l_auteur la_reference la_description Certaines classes de SCOOP possΦdent des liens d'hΘritage entre elles. Seul l'hΘritage simple est utilisΘ dans l'organisation hiΘrarchique. Les classes sont dΘcoupΘes en cinq catΘgories, les classes spΘcifiques pour chaque protocoles, les classes pour la gestion des messages, les classes pour la gestion des tΓches, la classe Scoop pour l'interface commune des protocoles et la classe User pour l'utilisation et les test de SCOOP.. branche type_branche 2 l_index 31 nom_branche 4.1 - LES CLASSES PROTOCOLES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.1 - LES CLASSES PROTOCOLES niveau_branche 3 mots_cles l_auteur la_reference la_description Pour chaque protocole est dΘfini une classe principale ôPROTLöaddr (ETHaddr, ARPadr, etc ...) qui hΘrite de la classe Scoop, et dΘfinit les fonctionnalitΘs du protocole en question. D'autres classes complΦtent leur fonctionnement, mais n'ont pas de lien d'hΘritage, ce sont des classes isolΘes, nommΘes classes internes. Les classes internes du protocole ETH (driver ethernet) : ò Driver, Entete, Packet. Les classes internes du protocole ARP (Address Resolution Protocole) : ò ArpPak, arpstate, arpent. Les classes internes du protocole ICMP (Internet Control Message Protocole) : ò ICMPHeader, ICMPrefix, ICMPBadMsg, ICMPFormat, ò ICMPRedirect, ICMPErreur, ICMPTimeStamp, ICMPState. Les classes internes du protocole IP (Internet Protocole) : ò IPhost, IPheader, MSGlist, IPtimer, RR, IPstate, Activeid, ò ReassemblyKey, RTE, IPOption. Les classes internes du protocole UDP (User Datagram Protocole) : ò Header, Sstate, Activepid. branche type_branche 2 l_index 32 nom_branche 4.2 - LES CLASSES MESSAGES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.2 - LES CLASSES MESSAGES niveau_branche 3 mots_cles l_auteur la_reference la_description Les classes messages fournissent une panoplie de mΘthodes pour manipuler les objet messages au cours de leur passage dans les diffΘrentes couches rΘseau. Ces mΘthodes permettent entre autre la manipulation des en-tΩtes et le dΘcoupage/rΘassemblage des messages. Les classes messages : ò NMsg, Msg. branche type_branche 0 l_index 33 nom_branche 4.3 - LA GESTION DES TACHES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES niveau_branche 3 mots_cles branche type_branche 2 l_index 34 nom_branche 4.3 - LA GESTION DES TACHES full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES\4.3 - LA GESTION DES TACHES niveau_branche 4 mots_cles l_auteur la_reference la_description SCOOP offre un gestionnaire de tΓches fonctionnant α travers une liste chaεnΘe suivant deux types de queue : F.I.F.O. et L.I.F.O.. Chaque tΓche est dΘsignΘe par un appel de fonction ou l'exΘcution d'une mΘthode, ayant comme arguments les variables ôargcö, pour mentionner le nombre d'arguments, et ôargvö, pour la liste des arguments. Cette gestion existe α travers trois classes : Scheduler, ListeTache, et Tache, la premiΦre classe est la principale, et sert d'interface pour les besoins des autres objets dΘsirant gΘrer une liste de tΓches. branche type_branche 2 l_index 35 nom_branche 4.3.1 - LA CLASSE TACHE full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES\4.3.1 - LA CLASSE TACHE niveau_branche 4 mots_cles l_auteur la_reference la_description Elle possΦde les informations liΘes α une tΓche : ò un identifiant unique, ò la tΓche α exΘcuter avec ses arguments, ò un numΘro de prioritΘ, ò une pile, ò des pointeurs de chaεnage, et offre des services de rΘcupΘration, de destruction, et de modification d'informations liΘs α l'objet impliquΘ. branche type_branche 2 l_index 36 nom_branche 4.3.2 - LA CLASSE LISTETACHE full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES\4.3.2 - LA CLASSE LISTETACHE niveau_branche 4 mots_cles l_auteur la_reference la_description Elle ne possΦde que deux pointeurs de liste, un de fin de liste et un autre de dΘbut. Ses services ciblent uniquement la manipulation des listes ainsi que des tΓches α travers une liste. branche type_branche 2 l_index 37 nom_branche 4.3.3 - LA CLASSE SCHEDULER full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES\4.3.3 - LA CLASSE SCHEDULER niveau_branche 4 mots_cles l_auteur la_reference la_description Elle gΦre l'ordonnancement des tΓches appartenant α une liste. A chaque objet Scheduler est associΘe une liste gΘrΘe par des mΘthodes de rΘcupΘration et d'insertion des tΓches suivant le type de queue choisie. branche type_branche 2 l_index 38 nom_branche 4.3.4 - LA HI╔RARCHIE full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.3 - LA GESTION DES TACHES\4.3.4 - LA HI╔RARCHIE niveau_branche 4 mots_cles l_auteur la_reference la_description La hiΘrarchie de la gestion des tΓches se dΘcompose en trois classes principales. La classe Scheduler hΘrite des deux autres classes, ce qui lui configure α la dΘclaration d'un objet, les mΘthodes et services des autres classes, et surtout une gestion transparente dÆune ou plusieurs listes, par lÆobjet qui utilise les services de la classe Scheduler. branche type_branche 2 l_index 39 nom_branche 4.4 - LA CLASSE SCOOP full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.4 - LA CLASSE SCOOP niveau_branche 3 mots_cles l_auteur la_reference la_description La principale fonction de la classe Scoop est de dΘfinir l'interface virtuelle des protocoles de communication (IP, UDP, ICMP, ARP, ETH). Les mΘthodes appartenant α l'interface commune sont dΘfinies dans la classe Scoop comme mΘthode virtuelle (notion de polymorphisme). Ces mΘthodes sont redΘfinies au niveau de chaque classe de protocole qui hΘrite de la classe Scoop. Ainsi pour une mΘthode donnΘe, il existe pour chaque classe de protocoles une mΘthode qui est personnalisΘe pour chaque protocole. Prenons l'exemple de la mΘthode Push () qui est dΘfinie comme mΘthode virtuelle dans la classe Scoop et qui est redΘfinie dans les classes UDPaddr et IPaddr. DΘfinition de la classe supΘrieure Scoop : DΘfinition de la classe IPaddr qui hΘrite des propriΘtΘs de la classe parent Scoop : DΘfinition de la classe UDPaddr qui hΘrite des propriΘtΘs de la classe parent Scoop : Ainsi l'appel de la mΘthode Scoop::Push () avec le protocole IP permet d'appeler la mΘthode IPaddr::Push () de maniΦre transparente. Il n'est pas obligatoire pour une classe hΘritant de la classe Scoop de redΘfinir une mΘthode virtuelle. Par exemple la classe ARPaddr hΘrite bien de la classe Scoop mais ne comporte pas de mΘthode Push (). branche type_branche 2 l_index 40 nom_branche 4.5 - LA CLASSE USER full_path SCOOP.MMO\4 - ORGANISATION HI╔RARCHIQUE DES CLASSES\4.5 - LA CLASSE USER niveau_branche 3 mots_cles l_auteur la_reference la_description La classe User permet de tester et dÆutiliser S.C.O.O.P.. Elle hΘrite de la classe Scoop pour Ωtre aisΘment manipulΘe par les objets polymorphes du graphe. La classe User correspond au niveau applicatif de SCOOP. Elle simule la couche utilisateur de lÆapplication. Elle se situe dans la hiΘrarchie des classes au mΩme niveau que les protocoles pour les manipuler aisΘment. Ne faisant pas partie de lÆinitialisation du graphe de dΘpart, lÆobjet User crΘΘ possΦde certaines mΘthodes de lÆinterface virtuelle qui lui permettent dÆenvoyer et de recevoir des messages. ConstituΘe principalement de deux mΘthodes : Client et Server, lors de lÆappel α la mΘthodes d'initialisation de la classe, une tΓche est gΘnΘrΘe, et est considΘrΘe soit comme application de type client, ou soit comme application de type serveur, suivant le mode de lancement. Le fait de crΘer une classe User hΘritant de la classe Scoop, permet une manipulation plus fine de lÆensemble de toutes les classes. En utilisant la classe User on comprend mieux la facilitΘ de crΘer un nouveau protocole et de lÆinsΘrer dans la hiΘrarchie existante, au lieu dÆavoir une architecture de couches statiques, il est plus intΘressant dÆavoir tous les protocoles au mΩme niveau et de les interconnecter α son grΘ. La classe User est crΘΘe pour mettre en Θvidence une des utilisations de SCOOP. branche type_branche 0 l_index 41 nom_branche 5 - FONCTIONNEMENT G╔N╔RAL full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL niveau_branche 2 mots_cles branche type_branche 2 l_index 42 nom_branche 5 - FONCTIONNEMENT G╔N╔RAL full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5 - FONCTIONNEMENT G╔N╔RAL niveau_branche 3 mots_cles l_auteur la_reference la_description SCOOP fonctionne α travers la crΘation d'un graphe de protocoles qui s'initialise au lancement de l'application (client ou serveur). NommΘ graphe polymorphe, car chacun des noeuds peut prendre la forme de l'objet protocole qui lui est assignΘ, il reprΘsente le chemin principal que prennent les messages. La seule chose qui n'est pas prise en compte, est la cohΘrence des envois de messages entre les diffΘrents protocoles, qui est laissΘe α la charge de l'utilisateur, cÆest-α-dire dans son choix de crΘation du graphe. Une fois le graphe constituΘ, une phase dÆinitialisation est lancΘe, qui est en partie une prise de connaissance des noeuds entre eux. Tous les noeuds sont des objets qui appartiennent α la classe Scoop, grΓce α l'interface virtuelle dΘfinie par cette classe, chaque protocole initialisΘ α l'intΘrieur de chaque noeud peut communiquer avec les autres α l'intΘrieur du graphe, soit dans le sens montant, vers l'application utilisateur, soit dans le sens descendant, vers le rΘseau. branche type_branche 2 l_index 43 nom_branche 5.1 - LÆINTERFACE VIRTUELLE full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5.1 - LÆINTERFACE VIRTUELLE niveau_branche 3 mots_cles l_auteur la_reference la_description LÆinterface virtuelle, appelΘe aussi interface commune, reprΘsente la partie principale de la classe Scoop, cÆest par elle que transitent les messages, et cÆest elle qui assure la modularitΘ de chaque protocole, ainsi que leur intΘgration dans le graphe. Elle est commune α chaque protocole grΓce α la notion de hiΘrarchie. Les mΘthodes sont dΘclarΘes virtuelles, et dans chaque sous classe il existe une mΘthode correspondante qui redΘfinit les actions de lÆobjet appelant. La notion de mΘthode virtuelle est ici trΦs importante, cÆest grΓce α elle que la notion de polymorphisme donne tout son potentiel α la manipulation des objets protocoles. Pour chaque objet de la classe Scoop, et pour chaque appel α une mΘthode virtuelle, ce ne sont pas les actions liΘes au type de lÆobjet, cÆest-α-dire sa classe, qui sont appelΘes, mais les actions de lÆobjet factorisΘ. Dans le cas o∙ lÆobjet Scoop scp1 considΘrΘ prend la forme dÆun objet obj1 dÆune sous classe UDPaddr, par exemple, au moment de lÆappel dÆune mΘthode de la classe Scoop, cÆest la mΘthode de la classe UDPaddr qui est appelΘe, α laquelle appartient obj1, dans la mesure o∙ cette derniΦre classe redΘfinit la mΘthode et ses actions, dans le cas contraire, cÆest la mΘthode de lÆobjet scp1 qui est appelΘe. branche type_branche 2 l_index 44 nom_branche 5.2 - LA COMMUNICATION ENTRE LES NOEUDS full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5.2 - LA COMMUNICATION ENTRE LES NOEUDS niveau_branche 3 mots_cles l_auteur la_reference la_description Son mode de fonctionnement peut Ωtre schΘmatisΘ par une couche qui enveloppe chaque protocole, qui permet α chaque message dÆΘvoluer dÆobjet en objet. Chaque noyau de ces nouvelles entitΘs est inconnu des autres, seule la partie extΘrieure est considΘrΘe comme visible LÆabstraction faite par lÆinterface virtuelle permet les envois de message α lÆintΘrieur du graphe. A chaque noeud, traversΘ par un message, le protocole associΘ lui applique ses mΘthodes et le renvoi au prochain noeud, et ainsi de suite, suivant le sens du message. Une fois le graphe crΘΘ et initialisΘ, SCOOP exΘcute les tΓches de lÆutilisateur qui a choisi le r⌠le de lÆapplication, soit en serveur, soit en client. Dans les deux cas, les messages sont remontΘs jusquÆα la racine du graphe, et sont ensuite laissΘs α la charge de lÆapplication utilisateur, la classe User donne une des possibilitΘs dÆutilisation du graphe. branche type_branche 2 l_index 45 nom_branche 5.3 - CR╔ATION DES OBJETS DE MODEL╔ SESSION full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5.3 - CR╔ATION DES OBJETS DE MODEL╔ SESSION niveau_branche 3 mots_cles l_auteur la_reference la_description A la maniΦre de x-Kernel, SCOOP reprend les modΦles Session et Protocole. La crΘation des objets de modΦle Session se fait α lÆinitialisation dÆune connexion entre un client et un serveur. Avant dÆenvoyer ses messages, lÆapplication cliente doit ouvrir une session sur le noeud du graphe de niveau infΘrieur, grΓce α la mΘthode virtuelleOpen () de la classe Scoop, avec comme arguments, lÆobjet protocole reprΘsentant lÆapplication, doit Ωtre reprΘsentΘ par un objet polymorphe de la classe Scoop, le noeud du protocole dΘsirΘ (UDP, IP, ETH, ...), reprΘsentΘ aussi par un objet polymorphe, celui-ci peut Ωtre aisΘment rΘcupΘrΘ par la mΘthode GetProtlByName () de la classe Scoop, et les participants de cette connexion. A lÆappel de la mΘthode virtuelle Open () sur un noeud du graphe, ce dernier se charge de rΘpercuter lÆappel sur le noeud de niveau infΘrieur, et ainsi de suite. A chaque rΘpercussion sur les noeuds infΘrieurs du graphe, un objet polymorphe de modΦle Session est retournΘ. LÆapplication cliente recevant en gage de bon dΘroulement de lÆappel, un objet de modΦle Session, par cet objet, lÆapplication peut envoyer ses messages sur le protocole choisi. Par la crΘation de ces objets de modΦle Session, une liaison dynamique est crΘΘe, elle garantit lÆacheminement des messages dÆune connexion, il est ainsi possible d'ouvrir plusieurs connexions pour des acheminements diffΘrents. branche type_branche 2 l_index 46 nom_branche 5.4 - LÆACHEMINEMENT DES MESSAGES full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5.4 - LÆACHEMINEMENT DES MESSAGES niveau_branche 3 mots_cles l_auteur la_reference la_description Les messages sont transmis α travers le graphe grΓce α deux principales mΘthodes : Push () et Pop (). La premiΦre pousse un message dans le sens descendant, alors que la seconde pousse le message vers le sens ascendant. Dans le cas de plusieurs objets de modΦle Session pour un mΩme objet de modΦle Protocole, la mΘthode Demux () se charge de diriger le flux de messages vers le bon objet Session. branche type_branche 2 l_index 47 nom_branche 5.5 - LA GESTION DES MESSAGES full_path SCOOP.MMO\5 - FONCTIONNEMENT G╔N╔RAL\5.5 - LA GESTION DES MESSAGES niveau_branche 3 mots_cles l_auteur la_reference la_description Les Classes Msg et NMsg fournissent un jeu de mΘthodes pour manipuler les objets messages (ajout ou retrait des en-tΩtes, assemblage et rΘassembage des messages, etc...). La classe Map est utilisΘe par les protocoles pour diriger un paquet qui arrive d'un protocole de niveau supΘrieur, ou infΘrieur, vers l'objet Session appropriΘ. Ces mΘthodes reprennent en grande partie la librairie message fournie dans x-Kernel. Le message est composΘ de trois ΘlΘments : ò Une pile qui englobe les en-tΩtes du message. ò Un index qui reprΘsente le haut de la pile. ò Un pointeur vers un graphe de buffer qui englobe les donnΘes. Le principale avantage de cette structuration des messages est que les en-tΩtes sont ajoutΘs ou enlevΘs en manipulant la pile, sans recopier le message. Lorsque le message est de petite taille il est contenu dans la pile. Lorsque le message est plus important il est reprΘsentΘ par un graphe acyclique. Lorsqu'un message parcoure les diffΘrents protocoles, des en-tΩtes sont ajoutΘs ou enlevΘs en dΘplaτant l'index du haut de la pile. Chaque protocole par lÆintermΘdiaire des mΘthodes virtuelles Push () et Pop () peut insΘrΘ, ou lÆextraire, son en-tΩte. Mais seule la mΘthode virtuelle Demux () extrait les informations de lÆen-tΩte pour diriger le message vers le bon objet Session, dans le cas ou le message vient du rΘseau. Lorsque le message ne peut plus Ωtre contenu dans la pile, la pile est de taille fixe et ne peut donc pas Ωtre agrandie, un dΘcoupage en forme de graphe est alors effectuΘe. Dans le schΘma suivant la structure du message est dans une Θtape intermΘdiaire, le message est trop grand pour faire partie de la pile, mais il est contenu dans un simple buffer. Avant dÆenvoyer un message dans le graphe des protocoles, il faut obtenir lÆouverture dÆobjets de type Session, qui, avec les participants de la communication, permettent de baliser le chemin que prennent les messages. Cet service sÆobtient par la mΘthode Open () de la classe Scoop. Cette mΘthode rΘpercute la demande sur lÆensemble du graphe, et renvoie lÆobjet de type Session, en rΘponse dÆun bon dΘroulement, ensuite il suffira dÆenvoyer les messages par lÆintermΘdiaire de cet objet, et grΓce au service de la mΘthode Push () de la classe Scoop. Chaque objet session sÆoccupe de gΘrer la liaison entre deux objets de type Protocole, et permet ainsi le dΘplacement des messages α travers les diffΘrents protocoles de communication. Dans le cas ou un message remonte du rΘseau, la mΘthode virtuelle Demux (), dirige le message dans son parcours, grΓce aux objets de la classe Map, qui sauvegardent dans une liste les diffΘrents objets Scoop de type Session, pour les diffΘrents protocoles existants. La gestion de cette liste est assurΘe par les mΘthodes de la classe Map, elle permet ainsi α chaque protocole de possΘder plusieurs objets de type Session, pour assurer les diffΘrents voyages α travers le graphe des messages. LÆobjet Map gΦre sa liste, par ôhash codingö , par lÆintermΘdiaire de clΘs, α travers une table, ainsi chaque protocole peut rΘcupΘrer lÆobjet de type Session correspondant au message arrivant. Les objets Map peuvent sauvegarder dans leur liste tout type dÆobjet, puisque leur services sont aussi utilisΘs pour y sauvegarder des objets de la classe.RTE, classe interne α la classe IPaddr. branche type_branche 0 l_index 48 nom_branche 6 - IMPL╔MENTATION D'UN PROTOCOLE full_path SCOOP.MMO\6 - IMPL╔MENTATION D'UN PROTOCOLE niveau_branche 2 mots_cles branche type_branche 2 l_index 49 nom_branche 6 - IMPL╔MENTATION D'UN PROTOCOLE full_path SCOOP.MMO\6 - IMPL╔MENTATION D'UN PROTOCOLE\6 - IMPL╔MENTATION D'UN PROTOCOLE niveau_branche 3 mots_cles l_auteur la_reference la_description SCOOP permet une implΘmentation simple d'un nouveau protocole de communication. La premiΦre rΦgle α respecter est l'hΘritage que ce nouveau protocole doit obtenir de la classe supΘrieure Scoop. Par cette simple adjonction le nouveau protocole implΘmentΘ gagnera en abstraction pour son utilisation α partir d'un objet Scoop. Mais pour une correcte coopΘration avec les autres protocoles, la classe principale de cette nouvelle implΘmentation doit obligatoirement possΘder l'interface virtuelle α toutes les classes dΘrivΘes de la classe majeure Scoop. Cette interface commune permet une utilisation immΘdiate de ces fonctionnalitΘs par d'autres objets, et inversement. En respectant ce minimum, la coordination entre les objets se fera automatiquement. A l'intΘrieur de la nouvelle classe, la crΘation et l'appel α des objets internes sont tout α fait acceptΘes. La nouvelle classe doit Ωtre considΘrΘe par les autres objets protocoles, comme une "boite avec des entrΘes", chaque objet effectue son travail sur le message dont il connaεt le format principal commun α toute la hiΘrarchie. branche type_branche 2 l_index 50 nom_branche 6.1 - IMPL╔MENTATION DE LA CLASSE UDPaddr full_path SCOOP.MMO\6 - IMPL╔MENTATION D'UN PROTOCOLE\6.1 - IMPL╔MENTATION DE LA CLASSE UDPaddr niveau_branche 3 mots_cles l_auteur la_reference la_description Dans le premier stade de lÆimplΘmentation il est nΘcessaire de modulariser la nouvelle classe en dΘtachant les diffΘrents services de la classe. La classe UDPaddr est la plus simple α implΘmenter, reprenant les fonctionnalitΘs de la couche UDP de x-Kernel, et nÆaffectant que trΦs peu les messages, son implΘmentation sÆest faite α travers les mΘthodes virtuelles de la classe Scoop. La classe UDPaddr ne possΦde que trΦs peu de mΘthodes non hΘritΘes de la classe supΘrieure, elle redΘfinit la majeure partie des mΘthodes. Reprenant les fonctionnalitΘs dÆune couche UDP standard elle affecte les messages α travers la classe Header interne, qui contient les informations : du ôchecksumö, de la taille, et des ports de communication du message qui transite par elle. Les classes sont dites internes, dans le cas o∙ elles correspondent α une spΘcificitΘ dÆun protocole, et ne sont connus dÆaucune autre classe que la classe principale du protocole, cÆest-α-dire ici UDPaddr. branche type_branche 2 l_index 51 nom_branche 6.2 - IMPL╔MENTATION DE LA CLASSE ETHaddr full_path SCOOP.MMO\6 - IMPL╔MENTATION D'UN PROTOCOLE\6.2 - IMPL╔MENTATION DE LA CLASSE ETHaddr niveau_branche 3 mots_cles l_auteur la_reference la_description La classe ETHaddr redΘfinit les mΘthodes hΘritΘes de la classe Scoop, et gΦre les messages avec la classe Driver. SCOOP Θtant un simulateur au niveau utilisateur, grΓce α la classe Driver, les objets ETHaddr envoient et reτoivent les messages, comme si ces derniers circulaient α travers un driver communiquant avec la carte ethernet de la station. La classe Driver sÆoccupe de lÆenvoi vΘritable des messages sur le rΘseau via le mΘcanisme des sockets. Dans le cas dÆune modification de SCOOP, par lÆajout dÆun dialogue direct avec la carte rΘseau, il suffira dÆajouter α la classe Driver une sous classe qui se chargera du dialogue. Le choix pourra alors se faire entre la simulation ou lÆaccΦs direct au rΘseau, par lÆintermΘdiaire dÆun objet Driver dΘjα existant dans la classe ETHaddr par le simple appel de tel ou tel service. branche type_branche 2 l_index 52 nom_branche 7 - COMPILATION ET PORTAGE full_path SCOOP.MMO\7 - COMPILATION ET PORTAGE niveau_branche 2 mots_cles l_auteur la_reference la_description Le choix d'un compilateur C++ est un ΘlΘment trΦs important en cas de portage d'une application. Le C++ n'est pas suffisamment normalisΘ, il est en Θvolution constante, de plus, la plupart dÆentre eux se contentent de gΘnΘrer du code C qui sera en suite recompilΘ. Pour SCOOP le compilateur g++ du GNU a ΘtΘ choisi pour sa plate-forme qui peut Ωtre installΘe sur de nombreuses machines (HP, SUN, SONY, PC compatibles, etc ...), ce qui garantit, dans le meilleur des cas, un code indΘpendant du matΘriel, dans le soucis d'Θcrire un code C++ "portable", car malgrΘ les caractΘristiques de ce langage de haut niveau, le C++ est loin d'Ωtre implΘmentΘ de la mΩme maniΦre sur toutes les machines. C'est pour toutes ces raisons, que SCOOP a ΘtΘ testΘ avec d'autres compilateurs, dit conforme AT&T : sur SONY, HP, SUN, et micro-ordinateurs (PC : Turbo C++, Commodore Amiga : Lattice C++). Il s'est avΘrΘ que certaines implΘmentations C++ sont α manipuler avec prudence. La liste de toutes ces anomalies ne sera pas ici dΘtaillΘe, mais quelques particularitΘs utilisΘes dans SCOOP sont α dΘtailler. Les pointeurs sur les mΘthodes et leur utilisation par des objets de types diffΘrents peuvent Ωtre α l'origine de nombreuses erreurs de programmation. Avec le langage C l'utilisation de pointeurs sur fonctions est trΦs facile, et cette facilitΘ se retrouve avec le C++, la difficultΘ commence quand il s'agit de pointeurs sur les mΘthodes d'un objet particulier manipulΘ par un autre objet de type diffΘrent. En C++ il est possible de prendre l'adresse d'une fonction membre, le principal inconvΘnient est qu'il est obligatoire de prΘciser le type du pointeur [str86]. Et suivant les compilateurs cette implΘmentation est plus ou moins stricte, ou bien oblige une grammaire diffΘrente, ce qui peut obliger une hiΘrarchie non souhaitΘe pour arriver au service voulu. L'utilisation du type ôconstö, α la place de certain ô#defineö n'est pas toujours ce qu'il y a de mieux α faire, surtout pour certain passage d'argument aux mΘthodes, qui modifie la valeur de l'argument concernΘ, le compilateur C++ sur SUN est le seul α se ôplanterö littΘralement sans donner la moindre indication. Le passage d'argument implicite est souvent proscrit, ce qui oblige α prΘciser le type exact de l'argument par des conversion de types souvent abusifs et pouvant apparaεtre inutiles. branche type_branche 2 l_index 53 nom_branche 8 - ORGANISATION ET LANCEMENT DE S.C.O.O.P. full_path SCOOP.MMO\8 - ORGANISATION ET LANCEMENT DE S.C.O.O.P. niveau_branche 2 mots_cles l_auteur la_reference la_description Les sources de S.C.O.O.P. se regroupent dans un rΘpertoire Scoop, comprenant deux rΘpertoires principaux : inc : qui contient tous les fichiers include .h, qui possΦdent en grande partie les dΘfinitions des classes. src : qui contient les fichiers sources .cc. Ils possΦdent les sources des mΘthodes des classes, et vont donc de paire avec les fichiers du rΘpertoire inc.. Pour chaque classe dΘfinie, il existe, un ou plusieurs fichiers ôincludeö et un fichier source. Par exemple pour la dΘfinition dans SCOOP du protocole UDP, il existe un fichier udp.cc qui contient uniquement la dΘfinition des mΘthodes, un fichier udp.h pour la dΘfinition de la classe UDPaddr, et un fichier udp_i.h pour la dΘfinition des classes internes α la classe UDPaddr. Les autres rΘpertoires sont : ò RCS : contient les versions de lÆensemble des fichiers. ò tmp : pour les fichiers temporaires. Les autres fichiers sont : ò bmakeobj : fichier makefile pour la gΘnΘration de fichiers objets de compilation. ò bmakebin : fichier makefile pour la gΘnΘration de fichiers binaires de compilation. ò mkc : lance une compilation totale de SCOOP. ò mkr : lance un archivage RCS des fichiers modifiΘs. ò version : script kshell de gestion des versions de lÆensemble des fichiers. Pour compiler en mode ôdebugö, et obtenir la trace de lÆexΘcution du programme il suffit de lancer la compilation avec le script mkc et lÆoption -g. > mkc -g Une fois lÆexΘcutable, nommΘ main, crΘΘ, il suffit de le lancer soit en mode client soit en mode serveur. Pour cette exΘcution on considΦre quÆune application est attachΘe α SCOOP pour le bon fonctionnement de lÆexΘcutable. La classe User dΘfinit dans les fichiers user.h et user.cc est un exemple dÆutilisation. > main -s -p <numero_de_port > # en mode serveur. > main -c <serveur> -p <numero_de_port> # en mode client. Dans la crΘation dÆun systΦme de communication orientΘ objet pour protocoles, un nouveau concept est apportΘ aux techniques de communication entre machines distantes. La maniΦre de vΘhiculer les messages nÆΘvolue que trΦs peu, lÆatout principal se trouve dans la modularitΘ dÆun tel systΦme, seuls les protocoles UDP/IP ont ΘtΘ implΘmentΘs, mais le principe de base est lα, pouvoir suffisamment modulariser des protocoles pour les interconnecter entre eux, ou les faire coexister, dans un minimum dÆeffort de gestion. Si un tel systΦme peut Ωtre dΘveloppΘ plus profondΘment, et gΘnΘralisΘ, la venue dÆun nouveau protocole ne serait plus un problΦme, mais reviendrait α une factorisation dans une hiΘrarchie dΘjα existante. De plus lÆΘvolution dÆun des protocoles nÆaffecterait pas lÆimplΘmentation des autres. Si on regarde S.C.O.O.P. avec du recul, nÆassistons nous pas α lÆΘmergence dÆune nouvelle norme ?, une de plus ?. Une norme dictant la maniΦre dÆimplΘmenter un protocole dans un systΦme qui superviserait la coordination de tous les protocoles. A partir du moment ou lÆon dΘsire un systΦme regroupant une compatibilitΘ la plus gΘnΘrale, il est nΘcessaire dÆΘdifier une base qui devra Ωtre respectΘe, ce minima, qui est commun α tous, pourra rΘunir les diffΘrents protocoles de communication. La notion dÆorientΘ objet aide α gΘnΘraliser un tel concept, puisquÆil est α la base mΩme du mode de programmation, la hiΘrarchisation et la rΘutilisation du code existant sont lα pour le rappeler. Forme dÆadressage dispersΘ, sur une table de taille limitΘe au nombre de clΘs utilisΘs. Une mΘthode permet dÆassocier α toute clΘ une valeur dans un interval donnΘ.