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é.
