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.
2 - CHOIX DE D╔VELOPPEMENT
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.
3 - PR╔SENTATION G╔N╔RALE
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.
4 - ORGANISATION HI╔RARCHIQUE DES CLASSES
4 - ORGANISATION HI╔RARCHIQUE DES CLASSES
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..
4.1 - LES CLASSES PROTOCOLES
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.
4.2 - LES CLASSES MESSAGES
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.
4.3 - LA GESTION DES TACHES
4.3 - LA GESTION DES TACHES
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.
4.3.1 - LA CLASSE TACHE
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Θ.
4.3.2 - LA CLASSE LISTETACHE
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.
4.3.3 - LA CLASSE SCHEDULER
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.
4.3.4 - LA HI╔RARCHIE
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.
4.4 - LA CLASSE SCOOP
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 ().
4.5 - LA CLASSE USER
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.
5 - FONCTIONNEMENT G╔N╔RAL
5 - FONCTIONNEMENT G╔N╔RAL
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.
5.1 - LÆINTERFACE VIRTUELLE
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.
5.2 - LA COMMUNICATION ENTRE LES NOEUDS
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.
5.3 - CR╔ATION DES OBJETS DE MODEL╔ SESSION
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.
5.4 - LÆACHEMINEMENT DES MESSAGES
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.
5.5 - LA GESTION DES MESSAGES
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.
6 - IMPL╔MENTATION D'UN PROTOCOLE
6 - IMPL╔MENTATION D'UN PROTOCOLE
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.
6.1 - IMPL╔MENTATION DE LA CLASSE UDPaddr
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.
6.2 - IMPL╔MENTATION DE LA CLASSE ETHaddr
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.
7 - COMPILATION ET PORTAGE
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.
8 - ORGANISATION ET LANCEMENT DE S.C.O.O.P.
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Θ.
