Vous êtes sur la page 1sur 79

Rf : 2003/ II /..

2003

Soutenu la session de Juillet

Universit Manouba

ECOLE NATIONALE DES SCIENCES DE LINFORMATIQUE

RAPPORT de Mmoire de Fin dEtudes


Prsent en vue de lobtention du titre dINGENIEUR EN INFORMATIQUE Par : DAGHFOUS Nama

SUJET :

tude et ralisation dun stack de communication rseau base sur le multicast

Nom du responsable : M. Anis BEN BRAHIM (MKS) Encadr par : M. Anis BEN BRAHIM (MKS) M. Beyrem SKOURI (MKS) M. Maher SALLEMI (ENSI)
Organisme Adresse Tl. : Market Knowldge Services : 24,rue Imam Errassa-Montplaisir 1002-Tunis : 71 840 040 Fax : 71 286 315

DEDICACE
La Fontaine a dit Rien ne sert de courir, il faut partir

point
Jy rajouterai Et prendre le bon chemin

A ma Maman A mon Papa A mes frres Sabeur & Mouhamed Anis A mes surs Nadia, Souad, Mounira & Karima, A mes beaux frres Moez & Mohamed A ma belle soeur Ebtissem A ma petite nice Zahia A mon future neveu A mes amis

A vous Nama

REMERCIMENT
Avant dentrer dans le vif du sujet, je voudrais adresser mes sincres remerciements tous ceux qui mont aide. Je tiens remercier particulirement aussi bien pour leur accueil, Mr Anis

BEN BRAHIM et Mr Beyrem SKOURI, mes encadrants, leur aide et leurs explications que pour leurs qualits humaines. Je tiens remercier galement mon encadrant interne Sans Mr Maher tous Sallemi mes pour avoir accept et mes d'encadrer ce projet et pour ses conseils judicieux. oublier enseignants enseignantes pour la formation quils mont donne. Mes remerciements vont galement

lensemble du personnel de la Socit MKS en

particulier Sofine, Maher, et Kaouther rgner. Je remercie tous mes

pour leur

disponibilit et pour la bonne ambiance qu'ils font

amis,

tout

particulirement mes amis de lENSI, pour leurs soutiens continus, leur aide et leurs conseils. Jadresse toute ma gratitude ma chre famille pour son amour.

Et bien sr je

remercie tous ceux que je

naurais pas d oublier Merci tous

. . .

: , ... ,

Rsum

Ce projet, ralis au sein de MKS, entre dans le cadre dun mmoire de fin dtudes en vue de lobtention du titre dIngnieur en Informatique. Le travaille consiste raliser un systme de notification boursire se basant sur une communication de groupe fiable et temps rel.

Mots cls : notification, multicast, communication temps rel, TCP, UDP, RTP, Qt.

Abstract
This work has been done within MKS to obtain the degree of an engineer in Computer Science. This work consists in carrying out a system of stock exchange notification being based on a reliable group communication and real time.

Keywords: notification, multicast, real time communication, TCP, UDP, RTP, Qt.

SOMMAIRE
SOMMAIRE......................................................................................................................6 Table de figures..................................................................................................................8 INTRODUCTION.............................................................................................................9 Prsentation du Sujet.......................................................................................................12 I.1 Le cadre general.........................................................................................................13 I.1.1 Les Caractristiques de la notification...................................................................14 I.1.2 Travail Demand................................................................................................15 I.2. La mthodologie ......................................................................................................16 Etude Thorique...............................................................................................................17 II.1. Les Protocoles ........................................................................................................18 II.1.1. Le Protocole TCP (Transmission Control Protocol) ......................................18 II.1.2. Le Protocole UDP (User Datagramme Protocol) ..........................................18 II.1.3. Le Protocole RTP (Real Time Protocol) ........................................................19 II.1.4. Le Protocole RTCP (Real-time Transfert Control Protocol)..........................21 II.2. Les Types de Communication ...............................................................................21

II.2.1. Lunicast...........................................................................................................21 II.2.2 .Le broadcast.....................................................................................................22 II.2.3. Le multicast......................................................................................................23 II.3. La notion de groupe multicast ...............................................................................23 II.4. Adressage................................................................................................................24 ........................................................................................................................................25 II.5.Porte de la diffusion ..............................................................................................25 II.6. Les Protocoles Multicast.........................................................................................26 II.6.1. Le protocole de gestion de groupe IGMP .......................................................26 II.6.2. Le routage multipoint ......................................................................................26 Spcification.....................................................................................................................29 III.1. Spcification des Besoins .....................................................................................30 III.1.1. Besoins fonctionnels.......................................................................................30 III.1.2. Besoins non fonctionnels................................................................................32 III.2. L Etude de lExistant............................................................................................32 III.2.1. La prsentation de la solution actuelle...........................................................32 III.2.2. Les critiques de la solution actuelle...............................................................34 III.3.1. Motivations pour l'utilisation des techniques de communication Multicast 34 III.3.2. Le problme de dploiement du routage Multicast .......................................35 III.3.3. Le service de transmission Multicast fiable ..................................................36 III.4. La Solution Retenue..............................................................................................39 Client de transport...........................................................................................................41 (1) Requte.....................................................................................................................41 (8) Rponse....................................................................................................................41 Agent Multicast...............................................................................................................41 Serveur de transport........................................................................................................41 Module Rseau du Serveur.............................................................................................41 Agent Multicast...............................................................................................................41 Conception ......................................................................................................................42 IV.1 La communication entre entits distantes..............................................................43 IV.1.1. Lapproche unicast.........................................................................................43 IV.1.2 LApproche Multicast.....................................................................................44 IV.2. Messages Echangs...............................................................................................45 IV.2. 1. Format des messages.....................................................................................45 IV.2. 2. Types de messages envoys .........................................................................46 IV.3. Mcanisme de Fiabilit .........................................................................................46 IV.3.1. Anticipation ...................................................................................................46 IV.3.2. Retransmission...............................................................................................51 IV.4. Scurit..................................................................................................................52 Mise En uvre...............................................................................................................54 V.1. LEnvironnement de Ralisation............................................................................55 V.1.1. Environnement matriel..................................................................................55 V.1.1. Environnement logiciel...................................................................................55 V.1.3. Loutils de travail ............................................................................................55 V.2. Etat davancement...................................................................................................57 V.3. Le Chronogramme d'vnements...........................................................................59 CONCLUSION................................................................................................................60 BIBLIOGRAPHIE &NETOGRAPHIE..........................................................................61 Annexes............................................................................................................................64 Annexes A .......................................................................................................................65 Les sockets ......................................................................................................................65

Annexes B :......................................................................................................................70 Diagrammes de Classes...................................................................................................70 Annexes C : QT................................................................................................................74

Table de figures
FIGURE LGENDE PAGE

FIGURE 1 FIGURE 2 FIGURE 3 FIGURE 4 FIGURE 5 FIGURE 6 FIGURE 7 FIGURE 8 FIGURE 9 FIGURE 10 FIGURE 11 FIGURE 12 FIGURE 13 FIGURE 14 FIGURE 15 FIGURE 16 FIGURE 17 FIGURE 18 FIGURE 19 FIGURE 20 FIGURE 21 FIGURE 22 FIGURE 23 FIGURE 24 FIGURE 25 FIGURE 26

MCANISME DE NOTIFICATION DES CLIENTS TABLEAU ANALOGIE ENTRE LA NOTIFICATION BOURSIRE ET LE STREAMING LE SYSTME RALISER LENTTE RTP
LA PILE

12 13 14 18

TCP/IP & LUNICAST DANS UN WAN 21 LE LE MULTICAST DANS UN WAN

LUNICAST DANS UN LAN BROADCAST

20 21 21 22 23 24 29 29 31 33 36 39 41 42 44 45 47 47 49 54 55 56

LE MULTICAST DANS UN LAN & LES CLASSES DADRESSE

PORTE DE LA DIFFUSION EN FONCTION DU TIME TO LIVE


NTERACTION DU CLIENT AVEC LE SYSTME

INTERACTION DU SERVEUR DE DONNES AVEC LE SYSTME SOLUTION ACTUELLE SOLUTION MULTICAST REDONDANCE DE LINFORMATION
LA

SOLUTION RETENUE

COMMUNICATION UNICAST NOTIFICATION ADAPTATION DE LA TECHNIQUE FEC ANTICIPATION PAR LUTILISATION DES FEC ANTICIPATION COT SERVEUR ANTICIPATION COT CLIENT RETRANSMISSION COT SERVEUR
TEMPS A MEUSURE

RSULTATS DE TESTS CHRONOGRAMME

INTRODUCTION

u cours de ces dernires dcennies, le monde des affaires a connu une rvolution au niveau de la diffusion de l'information. En effet, les besoins croissants dune conomie, qui se veut internationale, voir intercontinentale,

base essentiellement sur la concurrence, sont la rapidit, la fiabilit et laccessibilit. Une mergence de nouveaux besoins en termes de service de transmission ont vu le jour. Parmi ces services, les mcanismes, visant fournir un moyen de communication de groupe bas sur le multicast, sont de plus en plus employs. Le multicast est une technique qui permet une source de distribuer des donnes un ensemble quasi illimit de clients, sans transmettre ces donnes autant de fois que le nombre de clients. Par consquent, le multicast permet dconomiser la fois les ressources du rseau et les ressources de la source de diffusion. Ce mcanisme semble particulirement bien adapt pour des applications grande chelle, comme par exemple, la tlconfrence, la diffusion de valeurs boursires ou la mise jour de logiciels. Cependant, un frein majeur au dveloppement de ces applications est le manque de fiabilit de ces communications. Actuellement, le service de diffusion multicast est un service non fiable et les taux de pertes sont non ngligeables. Donc, ces applications ncessitent un moyen qui leur garantie une meilleure transmission. Ainsi, mon projet de fin dtude s'inscrit dans le cadre de ces mcanismes qui visent fournir un moyen de communication de groupe fiable. En effet la socit MKS, agre en qualit de prestataire de services dsign auprs de nombreuse bourses, telle que la Socit de Bourse Franaise, la Bourse Electronique Suisse et autres, ma confi la conception et la ralisation dun systme de notification fiable et temps rel. fiabilit de

Ce prsent rapport, dtaille les tapes de mise en uvre du projet. Il comprend cinq parties : La premire prsente le contexte gnral du sujet. La seconde est consacre

une tude thorique. Pour mieux cerner le problme, la troisime partie spcifie les besoins des diffrents utilisateurs du systme et prsente les solutions envisageables pour sachever par la prsentation de la solution juge la plus adquate. Enfin, la quatrime et la cinquime partie abordent les tapes de conception et de ralisation du projet en question. .

Chapitre I

Prsentation du Sujet

e chapitre prsente le cadre gnral du projet. Il donne un aperu sur lorganisme daccueil et une premire description du

travail demand. Il sachve par la prsentation de la mthodologie utilise pour rsoudre la problmatique du projet.

Prsentation du Sujet

ENSI 2002/2003

I.1 LE CADRE GENERAL


La bourse est une institution trs ancienne. Les Romains avaient dj organis un march deffets de commerce et de devises. Au moyen ge, Bruges, un march se tenait dans lhtel de la famille Van der Burse , do le terme Bourse. De nos jours, les marchs financiers jouent un rle substantiel dans le dveloppement de lconomie contemporaine. Ces marchs se caractrisent par une volution dynamique et rapide, do le rle primordial des intermdiaires en Bourse. En effet, ce sont les intermdiaires qui acheminent les ordres des investisseurs et les notifient de lvolution boursire. Ainsi, mcanisme dchange dinformation se plus les sources dinformations du ngociateur sont jours, plus ses dcisions sont justes et plus son investissement est rentable. Le droule comme le montre la figure 1.

Bourses

Clients

lie

Prestatair e

Rseau
C lie n t

lie

n t

lie

Figure 1: Mcanisme de Notification des Clients

La socit MKS acronyme de Market Knowldge Services est spcialise dans le dveloppement des solutions pour le march boursier de passage dordre et de suivi dinformations boursires en temps rel. Dans ce cadre, elle cherche raliser un systme de notification en temps rel et fiable.

Projet de Fin dEtude

13

Prsentation du Sujet

ENSI 2002/2003

I.1.1 Les Caractristiques de la notification


Au cours des dernires annes, le volume des informations changes dans les bourses a doubl. En effet, dune part, le nombre des socits cotes ne cesse daugmenter. Dautre part, les valeurs boursires changent rapidement dtat. Ce qui amplifie le nombre de messages de notification transmettre aux clients. Cette notification requiert des moyens de transmission temps rel, efficaces et fiable. Sachant que la fiabilit doit tenir compte de la particularit suivante: si une information est perdue, alors il est plus rentable de retransmettre celle qui est la plus rcente, vu que linformation perdue peut devenir obsolte. Les caractristiques de la notification prsentent des ressemblances avec celles du streaming audio/vido comme lexplique le tableau suivant :

Notification Boursire Flux Nb dutilisateur Retransmission Service Continu Grand nombre Information la plus rcente Temps rel

Streaming audio/vido Continu Grand nombre Dernire scne Temps rel

Figure 2 : Tableau Analogie entre la notification boursire et le streaming

Projet de Fin dEtude

14

Prsentation du Sujet

ENSI 2002/2003

I.1.2 TRAVAIL DEMAND


La communication se fait entre des clients et un serveur : Le client est un demandeurs de services, Tel que les applications qui utilisent la base de donnes, les intermdiaires dans la bourse qui prennent des dcisions de vente ou dachat. Le serveur est lapplication qui excute les requtes et gnrent les messages de notification. Le travail demand consiste : Permettre aux clients de transmettre des requtes et de recevoir des messages de notification en temps rel. Permettre aux serveurs de recevoir les requtes des clients et de transmettre les rponses ainsi que la diffusion les messages de notification. Assurer une communication de groupe fiable. Prise en charge de laspect temps rel

Bourses
C L I E N T

Requte
Agent de Transport

Rponse/ Message de Notification

Requte
Agent de Transport

Transmission Requte
Agent de Transport

C L I E N T

Rponse/ Message de Notification

S R R V E U R

Rponse/ Message de Notification

Le Systme Raliser
Figure 3 : Le Systme Raliser

Projet de Fin dEtude

15

Prsentation du Sujet

ENSI 2002/2003

I.2. LA MTHODOLOGIE
Vu les avantages offerts par lapproche objet qui facilite la rutilisation des composants, la proximit du monde rel et la modularit, lutilisation dune mthodologie oriente objet simpose. Dans le cas de ce projet, la notation du langage UML savre la plus approprie et la plus efficace. Cest la notation standard pour la modlisation des applications construites laide dobjets. Elle se place comme le successeur naturel des notations des mthodes de Booch, OMT (Object Modeling Technique) et OOSE (Object Oriented Software Engineering) et, de ce fait, UML sest impos, la fois auprs des exploitants et sur le terrain de la normalisation. UML se concentre sur la description des artefacts du dveloppement de logiciel, plutt que sur la formalime du processus de dveloppement lui-mme : elle peut tre ainsi utilise pour dcrire les lments logiciels, obtenus par lapplication de diffrents processus de dveloppement. UML n'est pas une notation ferme : elle est gnrique, extensible et configurable par l'exploitant. UML ne recherche pas la spcification outrance : il n'y a pas une reprsentation graphique pour tous les concepts imaginables; en cas de besoins particuliers, des prcisions peuvent tre apportes au moyen de mcanismes d'extension et de commentaires textuels. Une grande libert est donne aux outils pour le filtrage et la visualisation d'information. UML fournit une panoplie d'outils permettant de reprsenter l'ensemble des lments du monde objet (classes, objets, ...) ainsi que les liens qui les relient. Toutefois, tant donn qu'une seule reprsentation est trop subjective, UML fournit un moyen astucieux permettant de reprsenter diverses projections d'une mme reprsentation grce aux vues. Une vue est constitue d'un ou plusieurs diagrammes. On distingue deux types de vues: 1. Les vues statiques, qui reprsentent le systme physiquement 2. Les vues dynamiques, montrant le fonctionnement du systme

Projet de Fin dEtude

16

Chapitre II

Etude Thorique

e chapitre est consacr une tude thorique qui prsente, en premier lieu quelques protocoles :TCP,UDP,RTP et RTCP. En second lieu,

elle introduit la notion du multicast et explique son mcanisme.

Etude Thorique

ENSI 2002/2003

II.1. LES PROTOCOLES


II.1.1. LE PROTOCOLE TCP (TRANSMISSION CONTROL PROTOCOL)
Ce protocole [n.1] offre un service fiable de remise de paquets, orient connexion, au-dessus du protocole IP. TCP garantit la remise des paquets et l'ordre appropri des donnes. De plus, il fournit une somme de contrle qui vrifie l'intgrit de l'en-tte des paquets et des donnes qu'ils contiennent. Si un paquet TCP est endommag ou perdu par le rseau au cours de la transmission, TCP retransmet ce paquet. Cette fiabilit fait de TCP un protocole bien adapt pour la transmission de donnes lors d'une session, pour les applications Client-Serveur et les services importants. [n.1] Cette fiabilit engendre des contraintes : en effet, des bits supplmentaires sont ncessaires afin de remettre les informations dans l'ordre appropri ainsi qu'une somme de contrle (checksum) obligatoire pour garantir la fiabilit des paquets TCP. Afin dassurer la bonne remise des donnes, le destinataire doit mettre un accus de rception. Ces accuss de rception (ACK) gnrent un supplment de trafic sur le rseau et ralentissent le dbit de transmission des donnes mais en faveur d'une plus grande fiabilit.

II.1.2. LE PROTOCOLE UDP (USER DATAGRAMME PROTOCOL)


LUDP [n.1] offre un service de datagrammes au-dessus du protocole IP. Ce service est sans connexion et ne garantit ni la remise, ni l'ordre d'arrive des paquets dlivrs. Ceci permet d'changer des donnes sur des rseaux fiabilit leve sans utiliser inutilement des ressources rseau ou du temps de traitement pour grer les mcanismes de confirmation. Le protocole UDP prend galement en charge l'envoi de donnes d'un expditeur unique vers plusieurs destinataires en mme temps. Cette diffusion de groupe, appele diffusion multipoint ou multicast.

Projet de Fin dEtude

18

Etude Thorique

ENSI 2002/2003

II.1.3. LE PROTOCOLE RTP (REAL TIME PROTOCOL)


Le protocole RTP
[B.1]

fournit un cadre de transport gnral pour tout type de

donnes temps rel spcifi par Le RFC 1889. RTP permet dassurer une dlivrance de donnes de bout en bout avec la caractristique temps rel, comme pour la vido et laudio interactive. Gnralement les applications utilisant RTP au-dessus de la couche UDP pour offrir le mcanisme de multiplexage et de checksum; les deux protocoles contribuent dans les fonctionnalits de transport. Cependant, RTP est utilis avec dautres protocoles de transport autre que lUDP. RTP supporte le transport des donnes multicast, sil est offert par le rseau. Le rle principal de RTP consiste mettre en oeuvre des numros de squence des paquets IP pour reconstituer les informations dans lordre mme si le rseau sous-jacent change l'ordre des paquets. Plus prcisment, RTP permet : squence De contrler l'arrive destination des paquets. Ces fonctionnalits se basent sur lentte des paquets RTP indiqu par la figure suivante : Didentifier le type de l'information transporte, Dajouter des marqueurs temporels et des numros de

32 bits Version P X CC M Numro de Squence

Marque de temps Identificateur de la source de synchronisation (SSRC) Identificateur de la source contributrice (CSRC)

Figure 4 : Lentte RTP

Projet de Fin dEtude

19

Etude Thorique

ENSI 2002/2003

Voici la signification des diffrents champs de l'en-tte: Le champ Version V de 2 bits de longueur indique la Le champ padding P : 1 bit, si P est gal 1, le paquet

version du protocole (V=2). paquet. Le champ extension X : 1 bit, si X=1 l'en-tte est suivie Le champ CSRC count CC : 4 bits, contient le nombre Le champ marker M: 1 bit, son interprtation est Le champ payload type PT : 7 bits, ce champ identifie le Le champ squence number : 16 bits, sa valeur initiale d'un paquet d'extension. de CSRC qui suivent l'entte. dfinie par un profil d'application (profile). type du payload (audio, vido, image, texte, html, etc.). est alatoire et il s'incrmente de 1 chaque paquet envoy, il peut servir dtecter des paquets perdus. Le champ Marque de temps (timestamp): 32 bits, reflte l'instant o le premier octet du paquet RTP t chantillonn. Cet instant doit tre driv d'une horloge qui Augmente de faon monotone et linaire dans le temps pour permettre la Synchronisation et le calcul de la gigue la destination. Le champ SSRC : 32 bits, identifie de manire unique la source, sa valeur est choisie de manire alatoire par l'application. Le champ SSRC identifie la source de synchronisation (ou dit simplement "la source"). Cet identificateur est choisi de manire alatoire avec l'intrt qu'il soit unique parmi toutes les sources d'une mme session La liste des CSRC identifie les sources (SSRC) qui ont contribu l'obtention des donnes contenues dans le paquet qui contient ces identificateurs. Le nombre d'identificateurs est donn dans le champ CC. donnes. Le champ CSRC : 32 bits, identifie les sources des contient des octets additionnels de bourrage (padding) pour finir le dernier

Projet de Fin dEtude

20

Etude Thorique

ENSI 2002/2003

II.1.4. LE PROTOCOLE RTCP (REAL-TIME TRANSFERT CONTROL PROTOCOL)


Le protocole RTCP
[B.1]

est bas sur des transmissions priodiques de paquets de

contrle par tous les participants dans la session. C'est un protocole de contrle des flux RTP, permettant de vhiculer des informations basiques sur les participants d'une session, et sur la qualit de service. Il mesure les performances, par contre il n'offre pas de garantie. Ces quatre protocoles se situent dan la pile TCP/IP comme suit

Applications RTP, RTCP TCP IP Ethernet, FastEthernet, FDDI, PPP, Figure 5 : la pile TCP/IP UDP

II.2. LES TYPES DE COMMUNICATION


II.2.1. LUNICAST
L'unicast permet une machine, dite source, de communiquer avec machine destinataire. La figure 6
[n.3]

une seule

illustre ce type de communication aussi bien au

niveau dun LAN quau niveau dun WAN : Si la source veut mettre un paquet plus

Projet de Fin dEtude

21

Etude Thorique

ENSI 2002/2003

dun destinataire, elle doit effectuer plusieurs communications point point afin de transmettre ce mme paquet chaque destination.

Figure 6 : Lunicast dans un LAN

&

Lunicast dans un WAN

II.2.2 .LE BROADCAST


Le broadcast permet une machine d'envoyer des messages toutes les machines en mme temps, comme lillustre la figure 7
[n.3]

. Cette technique semble trs puissante

puisqu'elle permet d'atteindre la totalit des machines, cependant, pour viter que des paquets transitent de manire irraisonne travers toute la plante, les routeurs les filtrent et les dtruisent. Ainsi, les paquets "broadcasts" ne franchissent pas les routeurs.

Figure 7 : Le Broadcast

Projet de Fin dEtude

22

Etude Thorique

ENSI 2002/2003

II.2.3. LE MULTICAST
Le multicast permet une ou plusieurs sources de communiquer avec plusieurs destinataires simultanment. Si une source veut mettre un paquet N rcepteurs, elle se contente dmettre un seul paquet adress un groupe qui reprsente ces N rcepteurs comme lillustre la figure 8
[n.3]

. Ce mcanisme est aussi bien valable au niveau dun

LAN quau niveau dun WAN.

Figure 8 : Le Multicast dans un LAN &

Le Multicast dans un WAN

II.3. LA NOTION DE GROUPE MULTICAST


Pour le multicast, la notion de groupe est primordiale : Un groupe est un ensemble de machines. Il est dsign par une adresse IP. L'ensemble des membres d'un groupe est entirement dynamique. Cela signifie que toute machine peut, tout moment, se joindre au groupe ou bien le quitter. Il n'y absolument aucune restriction sur le nombre des membres d'un groupe ainsi que sur leur localisation physique. Une machine peut tre en mme temps membre de plusieurs groupes. Il n'est toutefois pas ncessaire d'tre membre d'un groupe pour y envoyer des messages. L'originalit d'un groupe multicast est qu'il peut tre la fois permanent ou non. Un groupe permanent est en fait un groupe qui possde une adresse assigne par une autorit. Notons que c'est l'adresse qui est permanente et non l'ensemble des membres d'un groupe : un groupe permanent peut contenir zro ou plusieurs membres. Les adresses IP, non assignes des groupes 23

Projet de Fin dEtude

Etude Thorique

ENSI 2002/2003

permanents peuvent tre utilises pour des groupes temporaires qui n'existent que sils comprennent au moins un membre. [n.4]

II.4. ADRESSAGE
Les adresses IP disponibles pour le multicast sont les adresses IP de classe D. Ce sont les adresses qui ont les 4 bits de poids forts configurs de la faon suivante : "1110".Cela se traduit, en notation dcimale, par les adresses comprises entre 224.0.0.0 et 239.255.255.255. La plage dadresse est ainsi dcoupe : 224.0.0.0 et 224.0.0.255 sont rserves pour le routage. 224.0.0.1 : reprsente lensemble des stations du sous rseau considr. il ny a pas dadresse pour lensemble des machines de lInternet. Cela reprsente approximativement 250 millions d'adresses. Puisqu' chaque adresse on peut associer un numro de port dans la plage de 1024 65535, il en dcoule un nombre quasi infini de possibilits d'adressage (16,000 milliards).

rseau

Station

B 10

rseau

Station

C 110

rseau

station

D 1110
Figure 9 : Les Classes dAdresse

adresse multicast

Projet de Fin dEtude

24

Etude Thorique

ENSI 2002/2003

II.5.PORTE DE LA DIFFUSION
La communication multicast se base sur le protocole UDP. Par dfaut, les datagrammes multicast sont envoys avec un TTL (time to live), qui par dfaut prend la valeur 1 correspondant au sous rseau local. Le TTL permet de contrler la porte de l'mission. Ce sont les routeurs multicast qui donnent un sens cette valeur, en implmentant des notions de paliers (figure 10). Le TTL est dcrment de 1 chaque fois que le paquet traverse un routeur [ .4].
N

Emetteur LAN Site Rgion Pays Continent Monde 0 1 1 16 32 48 64 128

Figure 10 : Porte de la diffusion en fonction du time to live

Projet de Fin dEtude

25

Etude Thorique

ENSI 2002/2003

II.6. LES PROTOCOLES MULTICAST


II.6.1. LE PROTOCOLE DE GESTION DE GROUPE IGMP
Les adresses multipoint sont gres par le protocole IGMP
[n.10]

(Internet Group

Management Protocol). Ce protocole permet aux machines de dclarer leur appartenance un ou plusieurs groupes auprs du routeur multipoint dont elles dpendent, soit spontanment soit aprs interrogation du routeur. Celui-ci diffusera alors les datagrammes destins ce ou ces groupes. IGMP comprend essentiellement deux types de messages : un message dinterrogation Host Membership Query utilis par les routeurs pour dcouvrir et/ou suivre lexistence de membres dun groupe. un message de rponse Host Membership Report dlivr en rponse au premier par au moins un membre du groupe concern. Les implmentations actuelles dIGMP sont caractrises par leur rapidit de dtection dabsence dabonn un groupe sur un rseau.

II.6.2. LE ROUTAGE MULTIPOINT


Plusieurs protocoles [n.10] de routage spcifiques ont t dvelopps ou sont en cours de spcification pour rsoudre les problmes suivants : comment atteindre les membres des diffrents groupes rpartis sur tout lInternet, comment construire les arbres dacheminement ? comment conomiser de la bande passante en nacheminant les paquets multipoint que l o il y a des membres des groupes correspondants ? comment optimiser les changes entre routeurs, faut-il mieux annoncer quels sont les groupes que lon souhaite recevoir ou ceux que lon ne veut pas recevoir ?

Projet de Fin dEtude

26

Etude Thorique

ENSI 2002/2003

Actuellement les protocoles de routage multipoint sont rpartis en deux familles : Les protocoles orients " forte densit de clients " (dense

mode) comme DVMRP (Distance Vector Multicast Routing Protocol ), MOSPF (Multicast Open Shortest Path First ) et PIM DM ( Protocol Independent Multicast Dense Mode ). Ces protocoles supposent quil y a des membres du groupe multipoint sur la plupart des rseaux et que labsence de membre constitue lexception pour laquelle il y aura transfert dinformations entre routeurs. Les protocoles orients " faible densit de clients " (sparse mode) comme CBT ( Core Based Tree ) et PIM SM ( Protocol Independent Multicast Sparse Mode ). Ces protocoles supposent, au contraire des prcdents, que les membres du groupe multipoint sont trs disperss et peu nombreux par rapport au nombre de rseaux desservis.

Projet de Fin dEtude

27

Etude Thorique

ENSI 2002/2003

Projet de Fin dEtude

28

Chapitre III

Spcification

vant daborder la conception et la ralisation, il est utile de bien spcifier les besoins des diffrents utilisateurs du systme. Il est

galement important de critiquer lexistant et de prsenter les solutions envisageables, afin de pouvoir trouver la solution la plus adquate.

III.1. SPCIFICATION DES BESOINS


Les applications boursires se caractrisent par limportance de notion du temps rel : Les clients doivent agir vite aux changements des donnes. Ils doivent recevoir les informations le plutt possible en temps rel. Ils ont besoin dun outil de suivie en temps rel qui leurs permet de reproduire ltat rel de la bourse et dagir en consquence.

III.1.1. BESOINS FONCTIONNELS


Pour une meilleure rsolution des problmes, il faut bien spcifier les besoins des utilisateurs. Ce qui suit expose les besoins de nos utilisateurs : Transmission des requtes des clients au serveur Les clients envoient au serveur des requtes tel que des ordres de vente ou dachats ou des simples interrogations de la base de donnes. Le systme doit assurer le transport de ces requtes. Transmission des rponses des requtes De mme, Le systme doit assurer le transport de la rponse chaque client ayant mis une requte de consultation. Transmission des messages de notification du serveur aux clients Suite a une mise jour de la base de donnes, le serveur doit notifier lensemble des clients intresss par ces modifications. La solution mettre en uvre doit assurer cette diffusion. Pour une meilleure comprhension des besoins, les deux diagrammes de cas dutilisation suivants dfinissent, sous forme dactions et de ractions, les limites du systme et les relations entre le systme et son environnement. Le premier diagramme de la figure 11, dcrit le comportement du systme du point de vue dun client. Le client est un demandeurs de services. Ce type dacteur regroupe toutes les applications qui utilisent la base de donnes, les intermdiaires dans la bourse qui prennent des dcisions de vente ou dachat.

Projet fin dEtudes

30

Figure 11: Interaction du client avec le systme

Le second diagramme de la figure 12 dcrit le comportement du systme du point de vue dun serveur de donnes. Ce dernier est lapplication qui excute les requtes et gnrent les messages de notification.

Figure 12 : Interaction du Serveur de donnes avec le systme

Projet fin dEtudes

31

III.1.2. BESOINS NON FONCTIONNELS


Les besoins non fonctionnels se rsument en les points suivants : Fiabilit Le systme doit sassurer que tous les membres d'un groupe reoivent les messages en tenant compte la plus rcente. Aspect Temps Rel Linformation change de manire continue Portabilit Il est prfrable que le code source de lapplication soit compatible entre plusieurs systmes. Modularit Lapplication doit tre modulaire et intgrable dans dautre systme ncessitant un tel module de communication. et rapide, ainsi elle doit arriver le plutt possible au client pour une meilleure prise de dcision. de la particularit suivante : si une information est perdu, il est plus pertinent de retransmettre linformation

III.2. L ETUDE DE LEXISTANT


III.2.1. LA PRSENTATION DE LA SOLUTION ACTUELLE
Actuellement la solution de MKS comprend les lments suivants : Un serveur principal. Des serveurs secondaires, qui reprsentent des clients pour le serveur principal Des Clients. Ces lments sont lis statiquement via des liaisons point point bases sur TCP sous forme darbre : le serveur principale diffuse linformation un certain nombre de clients y compris les serveurs secondaires. Ces derniers leur tour diffuse linformation dautre de clients.

Projet fin dEtudes

32

Cette solution se base sur lunicast, lors de la notification le serveur met le mme message autant de fois que le nombre de clients qui lui sont connects comme lillustre la figure suivante :

S e rv e u r

2
C lie n t

lie

S e rv e u r

S e rv e u r

lie

lie

lie

4
S e rv e u r

6 5

lie

lie

lie

lie

lie

lie

lie

Rseau Message de notification i; tape de la notification Figure 13 : Solution Actuelle

Projet fin dEtudes

33

III.2.2. LES CRITIQUES DE LA SOLUTION ACTUELLE


Cette solution utilise le protocole TCP qui lui garantie la fiabilit, mais elle prsente plusieurs lacunes tel que : Le surcharge du rseau : Le mme message est envoy autant de fois que le nombre de clients qui lui sont connects, ce qui pose un problme de scalabilit (ou passage l'chelle) en limitant le nombre de participants. Le cot de transmission important : cette solution est consommatrices de ressources : bande passante, un espace mmoire, temps. Le temps de latence important : pour arriver un client, un message passe par des serveurs intermdiaires pour tre retrait ce qui engendre des retards. Par consquent, la notification ne se faits pas en temps rel, alors que le temps est un facteur important pour la prise de dcision dans le domaine boursier.

III.3. LES SOLUTIONS ENVISAGEABLES


III.3.1. MOTIVATIONS POUR L'UTILISATION DES TECHNIQUES DE
COMMUNICATION MULTICAST

Plusieurs raisons justifient le recours la communication de groupe : La premire est la scalabilit (ou passage l'chelle) en terme de nombre de participants. Chaque information n'tant transmise qu'une seule fois, au lieu d'tre transmis individuellement pour chaque rcepteur. Une session peut contenir un trs grand nombre de rcepteurs sans que cela ne pose de problme de ressources. La seconde motivation, consquence directe de l'aspect scalabilit, est la rduction des cots de transmission : Economie de la bande passante, ainsi que lconomie des ressources des routeurs et celle de la source de donnes.

Projet fin dEtudes

34

La troisime motivation est l'augmentation des vitesses de transfert, par rapport la solution point point, lorsque le nombre de rcepteurs augmente, la bande passante du rseau d'accs n'tant pas partager.

1
S e rve u r

lie

lie

lie

lie

lie

lie

lie

lie

Rseau 1,2; tape de la notification Figure 14 : Solution Multicast

Message de notification

III.3.2. LE PROBLME DE DPLOIEMENT DU ROUTAGE MULTICAST


Au sein d'un rseau local, le trafic multicast est correctement et automatiquement achemin vers toutes les machines intresses. En effet, les commutateurs sont des quipements intelligents qui analysent les paquets IGMP grce auxquels les machines expriment leur intrt recevoir le trafic multicast. [n.14]

Projet fin dEtudes

35

Au sein d'un site, mettre en place un service de routage multicast est relativement ais, les protocoles sont largement rpandus et les problmes techniques sont limits. Par contre au niveau de l'Internet la situation est toute autre. Certains rseaux universitaires offrent un service de routage multicast tels le MBONE qui signifie "Multicast BackBone". Il s'agit d'un rseau virtuel qui prend place au dessus de portions du rseau physique Internet, pour supporter le routage des paquets multicast puisque cette fonction n'est pas encore implmente sur la majorit des routeurs du commerce. Plusieurs handicapes existent, d'ordre technique, ainsi certains aspects du routage multicast inter-domaines sont encore du domaine de la recherche, ou marketing (quel modle de tarification utiliser ?). Pour parer ces problmes, diffrentes solutions sont utilises, la plus courante et la plus simple tant le recours un rflecteur, c'est dire une machine connecte au MBONE et servant de relais aux correspondants n'ayant accs qu'au routage point point.

III.3.3. LE SERVICE DE TRANSMISSION MULTICAST FIABLE


Les applications reposant sur le multicast ont besoin de services supplmentaires,
[n.14]

en particulier une fiabilit totale ou partielle des changes. Ce problme est plus

complexe traiter en multicast qu'en point point vu que la source ne connatra en gnral pas le nombre et l'identit des rcepteurs (contrairement TCP). Plusieurs points ont t identifis comme critiques par le RFC 2357: la scalabilit Il s'agit du passage l'chelle en terme de nombre de rcepteurs essentiellement. le contrle de congestion Les sessions multicasts doivent avoir un comportement quitable vis vis des flux.

la scurit

Projet fin dEtudes

36

Dj complexe en point point, la scurit applique au multicast l'est encore plus amplifi par membres. lvolution du groupe et l'anonymat des

III.3.3.1. LA SCALABILIT ET

LE

MULTICAST FIABLE : LES PROBLMES

La notion de scalabilit applique au service de transmission multicast fiable pose de nombreux problmes rsoudre : Un trafic de contrle scalable Lenvoie dun acquittement (ou ACK) chaque paquet transmis ( la TCP) n'est gure envisageable a cause du risque dinodation du rseau. Lenvoie dun acquittement ngatif (ou NACK) systmatiquement chaque paquet non reu pose galement problmes. Ainsi si la perte a lieu prs de la source, alors un trs grand nombre de rcepteurs vont gnrer un NACK qui risquent alors de faire crouler la source. Des retransmissions scalables Transmettre les paquets perdus en point point celui qui en fait la demande n'est clairement pas envisageable. Une gestion de l'htrognit Au sein d'un groupe important les rcepteurs ont une forte chance d'tre largement htrognes de point de vue du rseau d'accs et des capacits de traitement.

III.3.3.2. LA SCALABILIT DU TRAFIC DE CONTRLE


Le trafic de contrle est utilis essentiellement la fiabilisation des transferts (paquets NACK voir ACK) et au contrle de congestion. Trois approches sont adoptes afin d'en limiter le volume. III.3.3.2.1. Lutilisation de mcanismes de suppression chez les rcepteurs Une premire approche
[n.14]

consiste limiter le nombre d'informations de contrle

qu'un rcepteur peut tenter d'mettre. Pour cela deux solutions principales existent :

Projet fin dEtudes

37

La premire consiste transmettre en multicast les paquets NACK. Ainsi tous les voisins ayant connu les mmes pertes de paquets, une situation courante en cas de perte par engorgement d'un routeur, seront informs qu'une demande de retransmission est transmise. De plus pour limiter les collisions causes par les NACK, chaque noeud utilise un temporisateur' dont la valeur est choisie alatoirement. Pour garantir une meilleure scalabilit, cette valeur devra dpendre de la distance la source. Cette solution ncessite une valuation du RTT entre chaque source et chaque rcepteur. Une deuxime solution consiste transmettre les NACK en point--point vers la source mais en utilisant un ``backof temporisateur'' exponentiel. Cette solution s'est avre tre bien plus scalable et est adopte par la plupart des propositions de multicast fiable orient NACK. III.3.3.2.2. LUTILISATION DU FORWARD ERROR CORRECTION (FEC) (FEC Les codes FEC [n.14] sont des codes correcteurs d'erreurs. Un paquet FEC peut ainsi se substituer n'importe quel paquet de donnes qui aurait pu tre perdu et ainsi viter la gnration de NACK. Deux utilisations peuvent en tre employes : Anticipation : la source suppose qu'il y aura un certain taux de pertes et ajoute systmatiquement dans le flux de donnes transmis des paquets FEC supplmentaires. Le problme est ici de savoir l'avance combien de FEC ajouter. En effet les tats rseaux voluant dynamiquement, et le nombre de FEC redondant doit tre constamment remis en cause.

Nouvelle Donnes

D a t a X Message n

Rajout du message n au message n

D a t a X D a t a Y Message n

Donnes Redondantes

Nouvelle Donnes

Projet fin dEtudes

38

Figure 15 : Redondance de linformation

Raction : Suite la demande de retransmission de certains paquets, la source transmettra en fait un certain nombre de paquets FEC sachant quils peuvent se substituer n'importe quel paquet de donnes et donc satisfaire plusieurs rcepteurs ayant subit des pertes diffrentes.

III.3.3.2.3. LUTILISATION D'ARBRES Une dernire solution


[n.14]

, relativement complexe mettre en place, consiste

organiser les noeuds du rseau sous forme darbre. Les noeuds de l'arbre permettront de supprimer des NACK redondants demandant la retransmission des mmes donnes. En effet, un nud recevant des NACK issus de deux branches infrieures nen met quun seul. Un nud permet galement d'agrger des ACK redondants lorsque tous les rcepteurs en dessous ont confirm avoir reu les donnes.

III.4. LA SOLUTION RETENUE

Projet fin dEtudes

39

La solution raliser doit pouvoir, dune part, permettre au client denvoyer leurs requtes. Dautre part, elle doit garantir au serveur une diffusion fiable et temps rel des messages de notification. Pour le premier point, les clients envoient, dune manire non rgulire et spare dans le temps, des requtes, dinterrogation et de mise jour de la base de donnes. Vue que dans ce cas la contrainte fiabilit est forte, une communication point point base sur TCP est la solution la plus adquate. En effet, le protocole TCP achemine des donnes de faon fiable. Cette fiabilit est assure par le mcanisme de retransmission des paquets perdus, or, pour le second point, la notification, il est plus rentable de transmettre linformation la plus rcente. De plus, les dlais engendrs par ces retransmissions sont incompatibles avec les contraintes temps rel. D'autre part, TCP ne permet pas la transmission multipoint. Ainsi, la solution utilisera le protocole UDP qui permet la transmission multipoint, et ne comporte pas de mcanisme qui augmente les dlais effectifs entre sources et destinations. Pour satisfaire laspect temps rel, les donnes seront encapsules dans des paquets RTP. En effet, ce protocole fournit, la source comme au destinataire, les meilleures conditions possibles pour les applications temps rel. Il fournit, galement, un numro de squence pour la remise en ordre des paquets. Toute fois ces protocoles, UDP et RTP, ne sont pas fiables do la ncessit dun mcanisme assurant la fiabilit de la transmission. Il existe deux grandes classes de solutions : une qui se basent sur une correction a priori tandis que lautre corrigent les erreurs a posteriori grce un mcanisme de retransmission, comme lexplique les paragraphes III.3.3.1. et III.3.3.2. La premire problme. Cependant solution est assez adquate notre la surcharge du rseau en son inconvnient rside dans

transmettant un mme paquet plusieurs fois. Dans notre cas, seule les numros de paquets seront retransmis : Les squences des message de notification, concernant chaque objets, sont sauvegards afin dtre ajouter au future messages concernant lobjet en question. Vue que le risque de perte persiste, car il est difficile dtre certain davoir transmis suffisamment dinformations. Do la ncessit dun mcanisme de retransmission : Les rcepteurs, en fonction des donnes reues, mettent ou non des demandes de retransmission.

Projet fin dEtudes

40

Client de transport
(1)

Requte

Client de Donnes
(G) (d)

Agent

(8)

Rponse

Unicast

Agent Multicast

(A) NACK

Message de Notification (c) (F) Messages de Notification +FEC (2)Requte (B) NACK (7) Rponse

Rseau
(b) Messages de Notification +FEC (E) (C) NACK (3)Requte (D) NACK (6) Rponse

Serveur de Donnes

Message de Notification (a)

Agent Multicast

Unicast

Agent

(5) Rponse
(4)

Requte

Serveur de transport

Transmission en unicast: mission de requtes et rception de rponses, cet change se fait selon lordre suivant 1, 2, 3, 4, 5, 6, 7,8 Notification en multicast: diffusion des message de notification, cette notification se fait selon lordre suivant a, b, c, d Retransmission: demande de retransmission (A, B, C, D) en unicaste et rmission en multicaste (E, F, G) FEC: Forward Error Correction NACK: un acquittement ngatif

Figure 16 : la Solution retenue

Projet fin dEtudes

41

Chapitre IV

Conception

pres avoir spcifi les besoins des diffrents utilisateurs du systme, ce chapitre prsentons, la conception de la solution retenue Une mthode de conception qui

moyennant la mthodologie UML.

simpose par son efficacit et son adaptabilit au projet raliser

Conception

ENSI 2002/2003

IV.1 LA COMMUNICATION ENTRE ENTITS DISTANTES


Comme signaler prcdemment, la solution raliser doit, dune part, permettre au client denvoyer leurs requtes. Dautre part, elle doit garantir au serveur une diffusion fiable et temps rel des messages de notification. En tenant compte, des caractristiques de ces deux types dchange et de nos besoins, nous avons opt pour deux approches :

IV.1.1. LAPPROCHE UNICAST


Les clients envoient, dune manire alatoire, des requtes, tel que des ordres dachat ou de vente, des interrogations de la base de donnes etc. Lacheminement de ces requtes se fait via une communication unicast base sur TCP. Le processus de communication se droule comme suit : Ltablissement dune connexion unicast entre le client et le serveur via une socket (voir Annexe). Lmission de la requte par le client. La rcupration de la requte par le serveur. Le passage de la requte et lidentificateur du client au serveur de donnes pour le traitement. Sil sagit dune requte dinterrogation, le serveur de donnes retourne une rponse qumet le serveur de transport son destinataire.

:unicastClient Requete Rponse

:unicastServer Requte + clientID Rponse +clientID

:dat aServer

traitement

Figure 17 : Communication Unicast

Projet de Fin dEtude

43

Conception

ENSI 2002/2003

IV.1.2 LAPPROCHE MULTICAST


Pour la notification, nous avons opt pour une communication de groupe, o le serveur reprsente la source et les clients sont les destinataires. Lorsquun client souhaite faire partie du groupe de receveurs, il sy adhre via une primitive JoinMulticastGroup en spcifiant ladresse du groupe quil souhaite rejoindre, ce qui est quivalent une inscription au service. Lorsque le client ne souhaite plus recevoir de messages de notification concernant un service, il lui suffit de transmettre une primitive LeaveMulticastGroup en indiquant ladresse qui ne lintresse plus. Du cot du serveur, suite au changement de chaque objet, le serveur de donnes lui met un message XML, ainsi que lidentificateur de lobjet modifi. Pour assurer la notification le serveur procde comme suit : Formuler le message envoyer : ajoutre au message XML une entte (dtaille dans le chapitre suivant). Encapsuler le message dans un paquet RTP. Diffuser le message au groupe. Mmoriser la correspondance entre la nouvelle squence et lidentificateur de lobjet.

Projet de Fin dEtude

44

Conception

ENSI 2002/2003

:dataSender

;builderMessage

:Sender

:Group

message XML + objetID

Message Squence

PaquetRTP

Figure 18 : Notification

le squ encement sert au mcanism e de fiabilit

IV.2. MESSAGES ECHANGS


Pour assurer la communications, les intervenants changes des structures de donnes : les messages. En interprtant ces messages, lexploitation des donnes devient possible.

IV.2. 1. FORMAT DES MESSAGES


Le format des messages mis en Unicast

Lg

Donnes

Le champ Lg ou longueur est sur 4 octets il indique la longueur du champs donnes. Le champ T ou type prcise le type du message (requte ou NACK). Les donnes ont une taille variable et consistent dune chane de caractres. La trame a donc aussi une taille variable

Projet de Fin dEtude

45

Conception

ENSI 2002/2003

Le format gnral des messages mis en Multicast En Tte RTP

Lg _ FEC

FEC

Donnes =Message XML

En plus de lentte RTP, Le champs Lg-FEC est sur cinq octets il indique la longueur du champ suivant FEC. Le dernier champ comprend les donnes changes. Le FEC ou Forward Error Correction permet de pallier aux pertes de la transmission et dviter aux clients de demander des retransmissions.

IV.2. 2. TYPES DE MESSAGES ENVOYS


Par le client: R : Requte (Unicast). N : acquittement ngatif qui informe le serveur de la liste des numros de squence des paquets perdu par objet (Unicast).

Par le serveur: A : envoie dune rponse une requte (Unicast). Les messages XML de notification (multicast).

IV.3. MCANISME DE FIABILIT


En utilisant le protocole UDP Multicast, on s'expose une perte de paquets possible. Pour pallier ce problme, la solution envisage procdera par anticipation et retransmission.

IV.3.1. ANTICIPATION
En utilisant la technique des Forward Error Correction (FEC) et en tenant comptes des deux proprits suivantes : une entit change rapidement dtat et cest son tat

Projet de Fin dEtude

46

Conception

ENSI 2002/2003

actuelle qui intresse le client, un message comprendra en plus de son numro de squence ceux des messages concernant la mme entit qui viennent dtre mis. Schmatiquement, considrons deux messages concernant le mme objet, dont lmission est spare par un court intervalle de temps champ FEC du second message correspond au champ squence et au champ FEC du message prddent comme lillustre la figure 19.

Squence { FEC { Nouvelle Donnes

l a t i a a X t a X X M L Message n

k a t l;i a a X t a X X M L Message n

} Squence } FEC

Nouvelle Donnes

Figure 19 : Adaptation de la technique FEC Pour expliquer davantage, considrons deux entit X et X, et un serveur qui notifie un groupe de leur changement respectifs selon le scnario suivant :

Serveur (seq=1; Fec= ;etat(X)=x) (seq=2 ; Fec= ;etat(X)=y) (seq=3 ; Fec=1 ;etat(X)=z) (seq=4; Fec=1,3 ;etat(X)=t) (seq=5; Fec=3, 4 ;tat(X)=l)
Projet de Fin dEtude

Groupe

47

Conception

ENSI 2002/2003

(seq=6 ; Fec= ;etat(X)=x) (seq=7, Fec=5 ; etat(X)=i) (seq=8, Fec= ;etat(X)=t)

Squenc e Perdue

Message perdu

Message reu

Temps dajout dune squence un message

Figure 20 : Anticipation par lUtilisation des FEC

Explication Les messages dont les squences sont 1et 2 correspondent respectivement aux objets X et X ont le champs FEC vide car ils sont les premier messages concernant ces objets en question. Les messages dont les squences sont 3 et 4 correspondants a objets X se perdent. Le message dont la squence est 5 arrive destination. A sa rception si le client allait demander une retransmission des messages 3 et 4 il labandonne car il sait que cest deux messages concerns X et il a ltat actuelle de X il est donc satisfait. Les messages, dont les squences sont 6 et 7 correspondants respectivement aux objets X et X, se perdent. Le message, dont la squences sont 8 correspondent respectivement a X, a le champs FEC vide car la dure de retransmission de la squence sest acheve par suite le message na plus de trace do la ncessit dune retransmission. 48

Projet de Fin dEtude

Conception

ENSI 2002/2003

Le temps dajout dune squence un message varie principalement en fonction de la charge du rseau. Pour trouver une valeur adquate cette dure le serveur commence par une dure assez importante et la diminue tant quil ne reoit pas de demande de retransmission. A la rception tel dune demande il augmente cette dure.

IV.3.1.1. ANTICIPATION COT SERVEUR


Suite au changement dun objet, le serveur de donnes gnre un message XML correspondant au nouvel tat de l'objet. Il met au serveur rseau ce message, ainsi que lidentificateur de lobjet (objetID). Le serveur rseau ajoute ce message la liste des squences des messages dj mis pendant la priode prcdente (FEC). Par suite, il est encapsul dans un paquet RTP et diffus aux membres inscrits au service en question, et la nouvelle squence (Squence) du paquet mis, est ajoute la liste des squences de l'objet.

:dataS ender

;builderM ess age

M anager

S ender

mes s age XM L + obj etID

m es sag e XM L + obj etID FE C M es sage Squenc e objec tID+ S quenc e

Figure 21 : Anticipation cot serveur

Projet de Fin dEtude

49

Conception

ENSI 2002/2003

IV.3.1.2. ANTICIPATION COT CLIENT


Lors de la rception d'un paquet, le client examine le champ FEC et le numro du paquet en question pour vrifier sil y a perte ou rcupration dinformation. En cas de perte, il va demander une retransmission des paquet portant les numros des squences perdues, comme lillustre le diagramme suivant.

:mcastSender

:unicastClient rtpPaquet NACK lostSequences

; Receiver

:Controlor

:dataClient

notificationMessage Squence+FEC si pert e

Figure 22 : Anticipation cot client

Le thread Receiver Ce thread attend quun message arrive en provenance du serveur. Aprs rception dun message, son champ de donne est mit lexploiteur de donnes. Le numro de squence ainsi que le champs FEC sont envoys au thread de contrle pour dtecter une ventuelle perte ou acquitter des pertes ultrieures. Pour des raisons de scurit, une vrification de lexpditeur est effectue sur toute trame reue. Le thread Controlor Ce thread mmorise la dernier numro de squence reu. A la rception dun nouveau numro il vrifie sil ny a pas de saut entre les deux numros. A chaque dtection de message perdu, il sauvegarde le numro perdu et lance un dlai de garde, en armant un temporisateur, afin dattendre un certain temps avant denvoyer un NACK dans lespoir de retrouver la squence perdu dans un futur FEC.

Projet de Fin dEtude

50

Conception

ENSI 2002/2003

A la rception dun FEC, il extrait les numros de squences repris et les supprime de sa mmoire par suite les temporisateur associ sont dsarms. En cas dexpiration dun temporisateur, il met un NACK.

IV.3.2. RETRANSMISSION
Lun des facteurs d'chec des stratgies de redondance est la perte de messages conscutifs. Dans notre cas, la probabilit que deux messages conscutifs concerne le mme objet nest pas trs forte, cependant le risque persiste, do l'utilit de la retransmission.

IV.3.2.1. RETRANSMISSION COT CLIENT


Suite la dtection de perte de paquets, le client nmet pas immdiatement un NACK. Il arme un temporisateur pour patienter pendant un intervalle de temps borne et gnre alatoirement pour viter d'inonder le serveur par des NACK et dans l'espoir de retrouver les squences manquantes dans les prochains paquets. Si le temporisateur expire, le client envoie en unicast un NACK des squences perdues.

IV.3.2.2. RETRANSMISSION COT SERVEUR


Lors de la rception d'un NACK comportant les numros de squence des paquets perdus, le serveur retrouves les objets correspondants ces paquets perdus. Il retransmet en multicast les derniers messages concernant les objets en question, car probablement d'autres membres n'ont pas reu ces mmes paquets perdus.

Projet de Fin dEtude

51

Figure 23 : Retransmission cot Serveur

Conception
:unic as tC lient NA CK :un ic as tS ender ;bu ilderM ess ag e Ma n a ger

ENSI 2002/2003
S end er

S q uence s

s qu enc es M es s ag e XM L+ F E C M es s ag e S qu enc e obje c tID + S qu enc e

IV.4. SCURIT
Le multicast rseau est particulirement bien adapt pour des applications commerciales grande chelle tel que la diffusion boursires. Cependant, Un frein majeur son est le manque de scurit des communications en multicast : Dune part, il suffit de connatre ladresse du groupe et le port pour sadhrer au groupe. Dautre part, toute source, faisant partie du groupe ou pas peut mettre des messages. Par suite des intrus peuvent injecter des faux messages.

Afin de faire face ces menaces, le systme permet de : Permettre au producteur de se protger contre les risques d'une usurpation d'identit moyennent le isol des autre machines. restreindre l'accs au contenu distribu en multicast aux seuls clients lgitimes de l'application en fixant le TTL de chaque paquet la valeur adquate (2 dans notre cas).Afin de sassurer que linformation ne dpassera pas le LAN. mcanisme de VLAN: Deux sous LAN sont interconnects par un switch, tel que le serveur forme un sous rseau lui seul

Projet de Fin dEtude

52

Conception

ENSI 2002/2003

Permettre au client de s'assurer de l'origine des donnes reues. En effets seuls les messages dont ladresse de lexpditeur correspond celle de la source sont accepts. Ladresse IP de la source est passe en paramtre au lancement du client. .

Projet de Fin dEtude

53

Chapitre V

Mise En uvre

ette partie constitue le dernier volet de ce rapport ; Elle a pour objet dexposer le travail achev. Pour ce faire nous allons prsenter

dabord lenvironnement de travail ainsi que les outils de dveloppement utiliss. Ensuite nous dcrirons les tests dvaluation de lapplication.

54

Mise en uvre

ENSI 2002/2003

V.1. LENVIRONNEMENT DE RALISATION


Ce paragraphe dcrit lenvironnement matriel mis la disposition du prsent projet comme il met en relief lenvironnement logiciel qui a permis laboutissement de cette application.

V.1.1. ENVIRONNEMENT MATRIEL


Cette application a t dveloppe sur une station de travail ayant les caractristiques suivantes : Processeur Pentium III 128 Mo de RAM Disque dur de capacit 10 Go Carte rseau : Ethernet

V.1.1. ENVIRONNEMENT LOGICIEL


Deux PC munies de : Windows 2000 Professionnel Microsoft Visual C++ 6.0 Microsoft Developper Network(MSDN) Microsoft Project Microsoft Office 2000 Qt dans sa version 3.1.1 (produit Trolltech)

V.1.3. LOUTILS DE TRAVAIL


V.2.3.1. PRSENTATION DE QT
Qt est une bibliothque de classes C++ permettant d'crire des interfaces graphiques multi-plates-formes de haute qualit. Elle est surtout fameuse pour avoir permis le dveloppement du projet KDE sous Linux, bien que les applications qui fassent appel Qt puissent tre compiles la fois sous Windows 95/98 ou Windows NT et sous Unix.

Projet de Fin dEtude

55

Mise en uvre

ENSI 2002/2003

QT se base sur le la communication vnementielle fonde sur deux concepts: les vnements et les ractions. Une raction est un traitement associ loccurrence dun vnement . Ce mcanisme est connu par le mcanisme Signal/Slots de QT, il permet la communication inter objet. Cest un dispositif central de QT et probablement la partie qui diffre le plus des autres toolkits . Dans la plupart des toolkits de GUI les widgets ont un callback de service pour chaque action qu'ils peuvent dclencher. Les applications de GUI rpondent aux actions d'utilisateur : des applications vnementielles. L'application excute un certain code pour rpondre chaque vnement fait par lutilisateur. Plus gnralement, le but est que tous les objets communiquer entre eux. appropri. puissent Le programmeur doit connecter des vnements au code

V.2.3.2 LA LIBRARY LIBRE JRTPLIB


JRTPLIB est une bibliothque LIBRE de RTP oriente objet, crite en C++. Il a t en partie dvelopp l'cole 'School voor Kennistechnologie' pour une coopration entre 'Limburgs Universitair Centrum' (LUC) et 'Universiteit Maastricht' (UM). La dernire version de la bibliothque est 2,7 (dcembre 12, 2002) actuellement, JRTPLIB cherche a supporter IPv6, et tre facilement extensible pour d'autres protocoles fondamentaux. cette bibliothque du protocole en temps rel de transport facilite l envoyer et la recevoir des paquets de RTP et les fonctions de RTCP (protocole de commande de RTP) sont manipuls entirement intrieurement. La bibliothque JRTPLIB est multi-plateformes elle supporte les suivants: GNU/Linux Mme.-Windows 95.98 et NT HP-ux Solaris VxWorks FreeBSD

Projet de Fin dEtude

56

Mise en uvre

ENSI 2002/2003

V.2. ETAT DAVANCEMENT


Le projet est environ 95% de sa ralisation : la phase de test les tests de validation afin de mettre laccs sur le rel gain apport par ce projet. Les test vise calculer le temps ncessaire entre lmission dun message du serveur de donnes et la rcupration de ce message par lagent de donns du client (figure 24) et le compar au rsultat de lmission en TCP. Ce temps comprend la transmission du message et son traitement afin de retrouv le message XML

Figur e I.1.2 : Serveur Temp s valu Agent De Donne XML


Semaine

Systme Ralis

Groupe

Rappo rt Test Ralisa tion Conce ption

Agent De Transport

Rseau

Agent De Transport

XML

Agent De Donne

Figure 24 : temps a meusure Spcifi


cation

Les mesures ncessitent des horloges synchronises entre les intervenant. Le calcul du temps aller retour (RTT) Permet de pallier au problme de synchronisation La mthode la plus simple pour calculer le RTT, est que le serveur envoie un message aux clients. Ces derniers retransmettent sur le champ les messages. Le RTT est gal deux fois la diffrence entre l'instant de rception de ce message et son instant d'mission vue que le temps de traitement est nul.

Projet de Fin dEtude

57

Mise en uvre

ENSI 2002/2003

Les premiers tests de mesures consistent mettre un nombre de paquets et mesurer le temps pour que tous les clients du groupe dont le nombre est de huit. aboutis aux rsultats suivants : Ces tests ont

Figure 25 : Rsultats de tests

la diffrence entre les deux courbes est le gain en temps apport par le systme ralis.

Projet de Fin dEtude

58

Mise en uvre

ENSI 2002/2003

V.3. LE CHRONOGRAMME D'VNEMENTS


Le dveloppement de cette application exig quatre mois de travail continue durant les quelles on a suivi un planning qui a t fix avec notre encadrant. Nous avons pass quatre semaines pour tudier et comprendre l'existant et rechercher la documentation ncessaire, trois semaines pour la spcification des besoins. La priode de conception a dur quatre semaines, et celle du codage sept semaines tous chauvauchant entre eux. Les tests se faisaient au fur et mesure de l'avancement de l'implmentation. Le chronogramme suivant est rcapitulatif

Rapport Test Ralisation Conception Spcification


Documentation et tude thorique

1 2 3 4 5 6 Figure 26 : Chronogramme

7 8 9 10 11 12 13 14 15 16

Semaines

Projet de Fin dEtude

59

CONCLUSION
Le projet que je viens de prsenter consiste concevoir et raliser un systme de notification boursire fiable et en temps rel. Le dveloppement dun tel systme permet un gain en bande passante ainsi quen temps, qui valent trs cher surtout dans le domaine financier. Ce projet ma t dapports bnfiques sur plusieurs niveaux. En effet, il ma permit dacqurir des connaissances importantes dans le domaine des communications et des rseaux, ainsi que le domaine de la bourse. En outre, il ma permis de travailler dans un environnement de dveloppement riche, savoir le framework QT, il ma permis galement une meilleure matrise du langage C++. Jai pu galement amliorer mon aptitude communiquer, collaborer et sintgrer lenvironnement professionnel. Une perspective ce travail, est son extension du LAN au WAN. Dans ce cas laspect scurit doit tre plus approfondit afin de fournir des services de confidentialit et d'authentification tenant compte des spcificits des applications multicast grande chelle. Une des possibilits est Lutilisation du protocole Express conu pour ces fins

BIBLIOGRAPHIE &NETOGRAPHIE
[b.1] J.F SUSBIELLE ,Internet multi media et temps reel, Eyrolles 2000 [b.2] Booch G., Jacobson I., Rumbaugh J Le Guide de l'Utilisateur UML. . Paris, Eyrolles 2000. [b.3] Pierre-Alain Muller, Nathalie Gaertner, "Modlisation objet avec UML", Eyrolles , Deuxime Edition 2000. [b.4] MATTHIAS Kalle Dalheiner, Programmer avec QT OREILLY, Seguier, 1999. [r.1] Rapport de mmoire de fin tude : ALOUINI Khalifa, MRABET Cyrine Implmentation dune Extension Multimdia sur IP ENSI 2002. [n.1] Yakham Ben Abdel Kader Ndiaye Mmoire de DEA Mise en uvre de larchitecture de communication des Structures de Donnes Distribues et Scalables RP*N et RP*C Disponible ladresse http://ceria.dauphine.fr/MemDEA_YNdiaye.pdf. [n.2] Ken Lindal UC Berkley IP Multicast: LAN toWAN Disponible ladresse http://www.cenic.net/Presos/Lindahl.pdf [n.3] Kevin Almeroth ,Santa Barbara IP Multicast: Modern Protocols, Deployment, and Management [n.4] L'Internet et le Groupware : Le Multicast Philippe Dax, Yan Pujante Ecole Nationale Suprieure des Tlcommunications Dpartement Informatique. [n.5] M. DOUGHAN, S. JAWHAR, Z.BITAR, S. MNEIMNEH Multicast Routing Protocols Disponible ladresse http://www.ordreingbey.org.lb/symposium/proceedings/22E_JAWHAR.pdf.

Bibliographie & Ntographie

ENSI 2002/2003

[n.6] Jean-Marie BONNIN Vers un service de diffusion Fiable A Grande Echelle : FAGE Disponible ladresse http://www.rennes.enstbretagne.fr/~bonnin/Public/Publications/theseResumeEtendu.pd f. [n.7]Qais AKASH Le Multicast et applications Disponible ladresse http://orange.u-strasbg.fr/DEA/01/DEA_01_Akash.pdf. [n.9]Alain PANNETRAT La Scurit des Communications en Multicast Disponible pannetra.pdf. [n.10]Http://www.cru.fr/multicast/presentation_mcast_mbone/presentation_mcast_mb one.article.fm.html [n.11] http://www.guill.net/reseaux/Routage.html [n.12] http://www.urec.cnrs.fr/cours/Reseau/routip2/index.htm [n.13] http://www.laissus.fr\cours\.html [n.14] http://www.inrialpes.fr/planete/people/roca/doc/jres01_rm_sota.html [n.15] http://www.trolltech.com/products/qt/whitepaper/qt-whitepaper.html [n.16] http://www.emse.fr/~mbeig/SOCKET/socket.html. [n.17] http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html [n.18] http://certa.u-bourgogne.fr/ressourc/labo/matsyst/multicast/.htm [n.19] htttp://www.toolinux.com/lininfo/magazines/linuxfocus/jan2001/art6/index ladresse http://rangiroa.essi.fr/riveill/rapports/2002/02-these-

Bibliographie & Ntographie

ENSI 2002/2003

Annexes

Annexes A Les sockets


A.1. LA DFINITION DUNE SOCKET
Une socket est une interface entre les programmes dapplications et les couches rseaux. De plus, le terme Socket dsigne aussi un canal de communication par lequel un processus peut mettre ou recevoir des informations. Elle permet la communication dans les deux sens.

Applicatio n

Applicatio n

Sock et

Rseau/Machine

Sock et

Communication via les sockets

Un socket possde trois caractristiques: Type: Dcrit comment les donnes sont transmises: SOCK_DGRAM, Domaine: Dfinit les formats dadressage utiliss: AF_INET Protocole: Dcrit les protocoles de transport (ou rseau) utiliss UDP, SOCK_RAW ICMP pour mettre et recevoir des donnes: SOCK_DGRAM TCP, SOCK_STREAM AF_UNIX,

SOCK_STREAM, SOCK_RAW

A.2. LA SOCKET & LA COMMUNICATION UNICAST


Deux mode de communication sont distingus : le mode connect et le monde non connect.

Mode Connect
Dans ce mode de communication le serveur et le client tablissent une connexion au pralable. Le serveur suit les tapes suivantes : Crer une socket. Se connecter au serveur en donnant ladresse de la socket distante (adresse Internet et numro de port ). Cette connexion attribue automatiquement un numro de port au client. Lecture ou criture sur la socket. Crer une socket. Se connecter au serveur en donnant ladresse de la socket distante (i.e.: adresse Internet et numro de port). Cette connexion attribue automatiquement un numro de port au client. Lecture ou criture sur la socket.
socket() bind() socket() Ouverture de la connexion

Le client suit les tapes suivantes :

listen()

accept()

connect()

read()/write() close()

Transfert de donnes

read()/write() close()

Fermeture de la connexion

Mode Non Connect


Dans ce mode de communication le serveur et le client ntablissent de connexion au pralable. Le serveur suit les tapes suivantes : Crer une socket Associer une adresse socket au service Lecture ou criture sur la socket.

Le client suit les tapes suivantes : Crer une socket Associer une adresse (i.e.: adresse Internet et numro de port) au service, Lecture ou criture sur la socket.

socket() bind()

socket() bind()

recvfrom()/ sendto()

Transfert de donnes

recvfrom()/ sendto()

close()

Fermeture de la connexion

close()

A.3. LA SOCKET & LA COMMUNICATION MULTICAST


Pour le multicast cinq nouvelles oprations de socket pour grer les options multicast. Setsockopt () et getsockopt () seront utilises pour tablir ou lire les valeurs de ce cinq options. Ces cinq opration sont : Option IPv4 IP_ADD_MEMBERSHIP IP_DROP_MEMBERSHIP IP_MULTICAST_IF IP_MULTICAST_TTL IP_MULTICAST_LOOP Description Adhrer au groupe Se retirer de groupe Spcifier une interface pour lenvoi de message Spcifier un TTL pour lenvoi de messages Activer ou dsactiver le loopback des messages

Emission/rception de paquets multicast


Envoyer des datagrammes multicast n'est fondamentalement pas diffrent de la programmation traditionnelle en l'unicast : on utilise des sockets. A l'heure actuelle seules les sockets AF_INET de type SOCK_DGRAM ou SOCK_RAW sont supportes. Il suffit donc

de crer une socket de ce type, puis d'envoyer ou bien d'couter sur l'adresse multicast dsire (pour couter il faut d'abord se joindre au groupe). En fait, plusieurs notions s'ajoutent celle de socket traditionnelle.

La premire notion est celle de TTL (Time To Live). La valeur initiale du TTL est configurable grce la fonction setsockopt() setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

Pour qu'une application puisse recevoir des datagrammes multicast, il est ncessaire qu'elle devienne membre d'un groupe. Cela se fait avec la mme fonction setsockopt() setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq,sizeof(mreq));

Pour quitter un groupe on utilise nouveau la mme fonction. setsockopt(sock, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq,sizeof(mreq)); Lorsque l'on joint un groupe, on ne spcifie que l'adresse IP du groupe. Pour le numro de port, il faut faire un traditionnel bind() sur ce port. Si l'on veut que plusieurs applications puissent utiliser la mme adresse de groupe (et donc le mme numro de port) sur la mme machine, il faut utiliser l'appel suivant: setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,&one,sizeof(one));

Gestion de l'arbre multicast


Une application peut se joindre tout moment un groupe. L'appel de setsockopt() avec IP_ADD_MEMBERSHIP fait que la machine devient membre du groupe spcifi (appelons le G). Pour cela, en utilisant le protocole IGMP qui se sert de l'adresse 224.0.0.1 (adresse du groupe de toutes les machines), la machine dclare au routeur multicast qu'elle fait partie du groupe G. Ainsi les paquets multicast qui arrivent au routeur en provenance de G seront transmis jusqu' elle. Si une autre application, sur la mme machine veut se joindre au mme groupe, l'appel systme n'a rien de particulier faire puisque les paquets arrivent dj jusqu' elle.

Lorsque l'on quitte un groupe avec IP_DROP_MEMBERSHIP ou bien en fermant la socket, il faut dire au routeur que l'on ne fait plus partie du groupe, de faon ce que les paquets ne soient plus envoys la machine. Toutefois si d'autres applications utilisent ce groupe, il ne faut pas le faire. On peut dire qu'une machine fait partie d'un groupe tant qu'au moins une application tournant dessus possde une socket ouverte vers ce groupe. Les routeurs dialoguent aussi entre eux pour grer dynamiquement ces groupes.

Annexes B : Diagrammes de Classes


Les classes du client :

Client groupsAddress unicastAdress groupPort unicastPort port name2 Client() ~Client() getgpAddress() setgpAddress() getunicastAddress() setunicastAddress() getport() setPort() getunicastPort() setunicastPort() tojoin() toleave() toConnect() toclose()

mcastClient myPort destAddes s destPort s everUnicas tA dress myRTPS ess myReceiver myCont rolor memberGroup() ~memberGroup() getPort() s etPort() getdestA ddess() s erdestA ddress() getdestP ort() s erdesrP ort() getseverUnicat Address () s etseverUnicast Server() joinGroup() leaveGroup() t oNack()

unicastClient tcpSocket hostPort hostAddress unicastClient() ~unicastClient() toRead() toSend() connectionClose() getPort() setPort() getAddress() setAdress()

RTPPackage

I=(a*I-C)%b C=(a*I-C)/b Rondam I C u0 a b Rondam() ~Rondam() init() toGenerate() Controlor lastSeq list_lostSeq randomGenerator timer Controlor() ~Controlor() run() toControl() toNack() Receiver RTPsess serverAdress Receiver() ~Receiver() getHeader() getData() run()

Les classes du serveur

cette classe connect le signial de Nack du unicastServer au slot sendAgain du macast server

myServer myunicastServer myMulticastServer mylistenPort mymcastport my AddressIP mygroupAddress myserver() ~myServ er() getAddressip() setAdressip() getgroupAddress() setgroupAdress() getlistenPort() setListenPort() getgroupport() setgroupPort()

unicastServer

mcastServer

Les classes de la communication en unicast


unicastServer listnerServer listClient unicastServer() ~unicastServer() newConnect() getRequest() toAnswer() toClaim() disConnect()

QServerSocket

QDataStream

QSocket

cliientSocket ID clientSocket() ~clientSocket() opname() toSend() connectionClose()

listnerServer port listnerServer() ~listnerServer() newConnect()

Les classes de la communication en multicast


mcastServer RTPPackage msgBuilder mySender mcast Sender() ~mcast Sender() s endNewMsg() s endAgain()

headerManager

RTPSession

Sender mybuildMsg sess Sender(RTPSession) ~Sender() sendMsg()

buildMessages myManager buildMessage() ~buildMessage() getLastMsg() setLastMsg() buildMsg()

FecManager period() listSubject FecManager() ~FecManager() getHeader() setHeader() getMsg() setMsg() findObject() isEmpty() newIndex()

QMap sequenceTimer objectID FEC Msg lastMsg sequenceTimer() ~sequenceTimer() newSeq() getFec() setfec() toFind() dropObject() dropSeq()

QTimer

seqTimer sequence timer nb periode seqTimer() ~seqTimer() notAddseq() dropSeq()

Annexes C : QT
B.1. LA BIBLIOTHQUE QT
B.1.1. Prsentation de QT
Qt est une bibliothque de classes C++ permettant d'crire des interfaces graphiques multi-plates-formes de haute qualit. Elle est surtout fameuse pour avoir permis le dveloppement du projet KDE sous Linux, bien que les applications qui fassent appel Qt puissent tre compiles la fois sous Windows 95/98 ou Windows NT et sous Unix. Qt est un produit de Trolltech (www.trolltech.com), commercialis depuis 1995. Il est actuellement utilis par des diffrentes compagnies leaders comme : AT&T, IBM, NASA, HP, Intel, Siemens, Ericsson et Xerox, et par de nombreuses autres petites compagnies et organismes. Qt 3.1 (Il est actuellement dans sa version 3.1.1) maintient la facilit d'utilisation et la puissance des versions prcdentes tout en ajoutant la fonctionnalit significative et prsentant de nouvelles classes. Les classes du Qt sont entirement dcrites pour rduire la charge de travail de dveloppeur, et fournissent des interfaces pour un apprentissage plus rapide. La bibliothque Qt est, et toujours a t, entirement orient objet. En plus des classes directement lies la programmation de GUI, le dveloppeur dispose avec Qt de fonctions portables gnriques, comme celles qui permettent d'accder au systme de fichiers et au rseau ou de manipuler la date et de l'heure. Autant dire qu'il est trs rare d'avoir crire du code spcifique la plate-forme de destination. Qt tourne actuellement pour 3 groupes de systmes d'exploitation : Unix (incluant Linux, HP-UX, Sun Solaris, Digital Unix, SGI Irix, IBM AIX, SCO Unix, et plusieurs variantes de BSD). La librairie Qt a t implmente utilisant les librairies X11 et le X Window system.

Windows (incluant Windows 95, 98, NT et 2000). La librairie Qt a t

implmente utilisant Windows GDI API et le Microsoft Windows window system. Qt/Embedded. Il s'agit des plate-formes Linux qui supportent la notion de "framebuffer".

Single-source Qt Application
Qt API

Qt/Windows GDI Windows OSs

Qt/X11 Xlib/X11 Server Unix/Linux OSs

Qt/Embedded Embedde Linux

Les plate-formes supportes par Qt

En rsume, parmi les aspects les plus frappants dans Qt, nous notons : une approche oriente objet trs souple, une flexibilit en run-time (les aspects d'une GUI peuvent tre changs et/ou ajouts en run-time). des composants indpendants et rutilisables : ce principe est connu sous le nom de "component programming" un mcanisme de communication inter-objets assez spcial connu sous le nom de 'Signals/Slots'. Ce systme remplace le mcanisme traditionnel de "callback" dans les autres toolkits.

B.1.2 La communication vnementielle


La communication vnementielle se base sur deux concepts: les vnements et les ractions. Une raction est un traitement associ loccurrence dun vnement . Le principe dattachement est dfinit comme une association dynamique entre un nom dvnement et une raction. Cest une communication anonyme qui se base sur une indpendance entre lmetteur et les consommateurs dun vnement.

E M E T T E U R S

Nom (type) Dvnement

Canaux de communication

vnements

vnements

R E C E P T E U R S

Communication par vnement

Mcanisme signal/slot
Le mcanisme Signal/Slots permet la communication inter objet. Cest un dispositif central de QT et probablement la partie qui diffre le plus des autres toolkits . Dans la plupart des toolkits de GUI les widgets ont un callback de service pour chaque action qu'ils peuvent dclencher. Les applications de GUI rpondent aux actions d'utilisateur : des applications vnementielles. L'application excute un certain code pour rpondre chaque vnement fait par lutilisateur. Plus gnralement, le but est que tous les objets puissent communiquer entre eux. Le programmeur doit connecter des vnements au code appropri.

Des toolkits plus anciens emploient les mcanismes qui ne sont pas type-safe , qui sont inflexibles, et ne sont pas orients objet. Trolltech a invent une solution appele des "signaux et les slots". Le signal/slot est un mcanisme puissant de communication inter objet qui peut tre employ pour remplacer compltement les callbacks employes par dautres toolkits . Le mcanisme signal/slots est flexible, entirement orient objet, et implment en C+ Ce mcanisme permet aux objets Qt d'mettre des signaux anonymes causant l'excution immdiate de fonctions slots (voir Figure.5.): Les signaux et les slots peuvent prendre tout nombre d'arguments de n'importe quel type. Ils sont compltement type-safe . Toutes les classes qui hritent de QObject ou un de ses sous-classes peuvent contenir des signaux et des slots. Des signaux sont mis par des objets quand ils changent leur tat d'une manire dont peut tre intressant au monde extrieur. C'est tout ce que fait l'objet pour communiquer. Il ne sait pas si quelque chose reoit le signal l'autre extrmit. C'est une vritable encapsulation d'information, et assure que l'objet peut tre employ comme composant de logiciel. Des slots peuvent tre employes pour recevoir des signaux, mais elles sont des membres normaux de lobjet. Une slot ne sait pas sil existe un ou plusieurs signaux relis elle. En plus, l'objet ne sait pas le mcanisme de communication et peut tre employ comme vritable composant de logiciel. On peut relier autant de signaux quon veut une slot simple, et un signal peut tre reli autant de slots quon dsire. Il est mme possible de relier un signal directement un autre signal (Ceci mettra le deuxime signal immdiatement toutes les fois que le premier est mis.) Ensemble, les signaux et les slots composent un mcanisme de programmation puissant .

Evnements externes

Emission de signaux

Slots

QObject ou classe QObject ou classe hritant de QObject hritant de QObject

QObject ou classe hritant de QObject QObject ou classe hritant de QObject QObject ou classe hritant de QObject

Evnements externes

Signal 1 Signal 2 Signal 3

Figure 30 : Mcanisme Signal/Slot de QT

Le systme Meta Object de Qt Outre le mcanisme signals/Slots, ce systme gre tout ce qui est RTTI (Run Time Type Information) et proprits dynamiques des objets. Il se base sur 3 choses : La classe de base QObject, La macro "Q_OBJECT" qu'on trouve dans la dclaration de la classe, Le compilateur "moc"(Meta Object Compiler) qui gnre le code Meta Object de toute classe hritant de QObject et mentionnant la macro "Q_OBJECT". Le code Meta Object contient des informations concernant la classe mre de l'objet, les proprits de l'objet qu'il est possible de rcuprer et de modifier dynamiquement, etc.