HAL Id: hal-01162142https://hal.archives-ouvertes.fr/hal-01162142

Submitted on 10 Jun 2015

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

Larchive ouverte pluridisciplinaire HAL, estdestine au dpt et la diffusion de documentsscientifiques de niveau recherche, publis ou non,manant des tablissements denseignement et derecherche franais ou trangers, des laboratoirespublics ou privs.

Analyse de solutions oprationnelles dapplications DDSsur rseaux distants

Akram Hakiri, Pascal Berthou, Slim Abdellatif, Michel Diaz, Thierry Gayraud

To cite this version:Akram Hakiri, Pascal Berthou, Slim Abdellatif, Michel Diaz, Thierry Gayraud. Analyse de solutionsoprationnelles dapplications DDS sur rseaux distants. Techniques de lIngenieur, Techniques delingnieur, 2013, pp.1-11.

https://hal.archives-ouvertes.fr/hal-01162142https://hal.archives-ouvertes.fr

Analyse de solutions operationnelles dapplicationsDDS sur reseaux distants

Akram Hakiri1,2, Pascal Berthou1,2, Slim Abdellatif1,2, Michel Diaz1,2, Thierry Gayraud1,21CNRS ; LAAS ; 7 Avenue du Colonel Roche, F-31077 Toulouse Cedex 4, France

2Univ de Toulouse ; UPS, INSA ; F-31077 Toulouse Cedex 4, FranceEmail : {Hakiri, Berthou, Slim, Diaz, Gayraud}@laas.fr

ResumeStimulees par la croissance de leur utilisation, tantdans le domaine militaire que dans le domaine civil, les appli-cations DDS (Data Distribution Service) connaissent une fortecroissance dans les reseaux a large envergure. Certaines ca-racteristiques de ces reseaux comme les longs delais, la limitationde la bande passante et linterdiction de lutilisation de certainsprotocoles dans les reseaux operationnels (tel le multicast reseau),rendent cependant difficile, voire impossible, leur mise en place.Cet article presente une proposition pour linterconnexion dap-plications DDS sur des reseaux distants. Est dabord analysee lapossibilite dutiliser le service de routage de la couche middlewareDDS a travers la mise en oeuvre dun pont-federe DDSpermettant dinterconnecter des domaines DDS distincts sur desreseaux etendus. Le concept de Proxy DDS qui, compare avecla solution precedente, permet de reduire le volume de traficechange sur le reseau, est ensuite propose.

Index TermsDDS, Service de Routage, Pont-Federe, ProxyDDS, Multicast.

I. INTRODUCTION

De plus en plus dapplications utilisant le service de dis-tribution de donnees DDS (Data Distribution Service) [1]sont deployees sur des reseaux etendus comme lInternet [2][3] [4] [5].

pour beneficier du service de distribution de donneesquoffre le middleware DDS comme par exemple lesapplications Peer-to-Peer, les applications multimedia, lesapplication de controle/commande, etc.

En effet, DDS presente une architecture produc-teur/consommateur qui permet aux applications decommuniquer tout simplement, par publication, linformationdont elles disposent et de souscrire a linformation dont ellesont besoin. Comme le decrit la figure 1, le modele conceptuelde la distribution de donnees dans DDS repose sur uneabstraction dun espace global (domaine DDS) de donneestypees partage entre des processus applicatifs producteurs(publisher) qui produisent certaines de ces donnees et desprocessus consommateurs (subscriber) qui en consommentcertaines [6].

Un participant peut publier et sabonner simultanement ades informations identifiees par nom de Topic. A partir deces declarations dintention (a produire ou a consommerun topic), le middleware DDS met automatiquement enrelation les producteurs et consommateurs qui se partagent

FIGURE 1: Espace de donnees partage de DDS

le meme topic ; DDS se charge alors de livrer les differentesvaleurs (egalement appeles echantillons) produites auxconsommateurs qui se sont declares interesses par le topic.Une application souhaitant produire un type de donnees doitattacher un DataWriter a un publisher. Le publisher est encharge de la distribution effective des donnees alors que leDataWriter est le moyen pour lapplication dindiquer aupublisher la presence dun nouvel echantillon. Un processusapplicatif souhaitant transmettre un nouvel echantillon utilisedonc un DataWriter pour activer au niveau du publisherla dissemination de la valeur de la donnee qui se fera enfonction de la QoS prevue.Du cote consommateur, un subscriber receptionne lesechantillons publies des Topics auxquels il a souscrit.Lapplication utilise de son cote un DataReader (un partype de donnees) pour recuperer les echantillons recus.Une application souhaitant consommer un type de donnees(specifie par un topic) doit donc attacher un DataReader a unsubscriber. Ce dernier engage, pour chaque type de donneesconsommees, une phase de souscription qui lui permet desassocier aux publishers respectifs. Cette souscription peutconcerner tous ou partie des echantillons dun topic en jouantsur les caracteristiques dun topic, a savoir le nom, la clefeventuelle (souscription a une instance) ou le contenu/valeurdes echantillons.DDS fournit la possibilite de specifier pour chaque type dedonnees plusieurs parametres de QoS (debit, latence, dureede validite,. . .), qui permettent de realiser une applicationdistribuee basee sur le besoin et la disponibilite de chaquetype de donnees (nous ne traitons pas les QoS DDS dans ce

travail).Linterconnexion dapplications DDS a travers des reseauxdistants necessite une communication multicast reseau pourreduire le volume de trafic echange. En consequence, pourgeneraliser lintegration dapplications DDS sur des reseauxetendus, il peut etre necessaire dajouter dautres domainesDDS distants. La possibilite dutiliser plusieurs domainespermet de separer les donnees circulant dans le reseau decelles dautres applications.Cependant, lintegration de DDS sur des reseaux distantsest confronte a de nombreux problemes de deploiement. Eneffet, les messages de decouverte des participants qui devrontetre envoyes en multicast sont bloques, le multicast IP estbloque au niveau des routeurs de bordure pour des raisonsde securite et de performance de routage. En plus, DDSpar defaut ne permet pas lechange de Topics partages avecdautres domaines DDS. Il est alors impossible de realiser unecommunication entre deux domaines DDS distincts. De plus,lutilisation de mecanismes de communication de la coucheapplicative comme le serveur DNS (Domain Name Server) etles proxies de niveau applicatif tel que les proxies HTTP nerepond pas au contraintes de communication temp-reel desapplications DDS.Lobjectif de ce papier est danalyser les solutions existantespermettant la mise en place dapplications DDS sexecutantsur des noeuds distants, basees sur le service de routage [7]propose par la couche middleware NDDS [8], et ensuite deproposer le concept de proxy DDS qui en comparaison auxsolutions existantes reduit le volume de trafic echange sur lereseau grande distance.Ce papier est organise comme suit : la section II traitelutilisation du service de routage de DDS dans le pont-federepour resoudre certaines de ces questions. La section IIIpresente le proxy DDS que nous avons propose pourresoudre les problemes rencontres lors du deploiement dupont-federe. La section IV decrit la plateforme de test etevalue les performances de la solution proposee. La section Vpresente la conclusion de ce papier et decrit les perspectivesde ce travail.

II. ANALYSE DES SOLUTIONS BASEES SUR LEPONT-FEDERE

Dans cette section, nous presentons la premiere solu-tion qui consiste a enrichir le service de routage de DDSpour implementer le pont-federe. Le pont-federe permet dedecoupler spatialement les entites DDS situees sur des reseauxdistants afin de deployer les applications DDS existantes demaniere transparente. Il permet dune part linterconnexiondes domaines DDS distincts situes sur des reseaux etendus(Domain-Bridge) et didentifier les differents Topics (par leursnom, cle et type) echanges dans les differents espaces departage de donnees (GDS) en jouant le role dun pont deTopics pour assurer lechange des donnees entre differentesapplications DDS.

A. Presentation du DDS Routing Service (DDS-RS)

Le service DDS-RS propose des fonctions de bridge DDS-to-DDS entre applications pour permettre la transformationde donnees. Ceci permet dutiliser les applications DDS sansles modifier meme si elles ont ete developpees en utilisant desdefinitions dinterface incompatibles. Cest souvent le cas lorsde lintegration dapplications existantes dans des systemesdeveloppes independamment. Il permet egalement doffrir lesfonctionnalites suivantes :

z Domain Bridging : permet de creer un pont entre desdomaines DDS. Le middleware seul ne permet pas das-surer un echange de Topic entre deux applications DDSqui utilisent des espaces de partages globaux differents.Ce service de routage assure alors la communicationentre un DataWriter et un DataReader situes dans desdomaines DDS differents.

z Topic Bridging : Le service classique de distribution dedonnees se fait par lechange dune meme instance dunTopic entre un DataWriter et DataReader, alors que ceservice permet aux differentes entites dechanger desTopics qui portent des noms et des instances differents.Il permet donc dassurer une interoperabilite entre desTopics differents.

z Data Transformation : Ce service est capable de trans-former des Topics en dautres. En effet, on peut le confi-gurer de telle sorte quil consomme certains Topics etles retransmette en changeant des valeurs dechantillonsde ces Topics. Cette fonction peut etre utilisee pourempecher les donnees privees detre publiees dans unreseau etendu.

z Configuration XML : Le comportement du DDS-RSpeut etre configure a laide de fichiers XML pourfaciliter sa manipulation.

z Full QoS Configuration : Parametre le service DDS-RSpour la prise en compte de la qualite de service par laconfiguration de profils de QoS dans des fichiers XML.

Pour permettre a des applications DDS de communiquer surdes domaines DDS distincts, nous introduisons la notion depont-federe pour se referer a un pont DDS qui utilise leservice DDS-RS. Ce pont-federe est realise avec les APIsde DDS sans introduire de nouveaux protocoles qui rajoutentde la complexite, sans pour autant perdre lavantage de lin-teroperabilite souhaitee. Dans le suite de cette section, nousnous focalisons sur les deux possibilites de configuration dupont-federe, a savoir le mode Domain Bridging et le modeTopic Bridging (ce dernier est decrit plus loin dans cepapier).

B. Solution basee sur le Domain-Bridge

1) Principe de Fonctionnement: La solution basee sur leDomain-Bridge permet dinterconnecter des espaces de par-tage de donnees DDS differents. Elle consiste a definir demaniere statique les differents participants en specifiant leursadresses IP respectives dans une variable denvironnementappelee "NDDS_DISCOVERY_PEERS". En consequent, leDDS-RS regarde dans cette variable toutes les adresses des

FIGURE 3: Configuration du service de routage pour connecter de domaines DDS differents

machines distantes et envoie les messages Discovery en unicasta chaque participant. Ce pont, montre sur la Figure 2, secomporte comme un unique federe different des autres ap-plications DDS. Il sassure que tout evenement ayant lieu surun producteur DDS est propage vers les autres consommateursDDS.

FIGURE 2: Mise oeuvre du service de routage de NDDS

Comme le montre la Figure 2, le participant DDS1 est confi-gure de telle sorte quil puisse decouvrir le pont-federe pourassurer la distribution des Topics entre le participant DDS1sur le domaine DDS0 et les participants DDS2 et DDS3 situesdans le domaine DDS0. Ainsi, le participant DDS1 transferetoutes les donnees presentes dans le domaine DDS 0 vers ledomaine DDS 1.Le pont-federe peut decouvrir les adresses IP des differentesmachines par la configuration dun fichier XML. La Figure 3nous permet de mieux comprendre la configuration et leprincipe du service. Ce fichier contient en plus de la descrip-tion des differents participants, une description des Topics atransferer durant la session et le comportement a suivre pour

les router vers differents domaines DDS. Les sessions DDScontiennent (entre autres) les informations suivantes : pour laSession1 nous definissons le domaine dentree comme Inputsuivi du participant qui va generer les differents Topics,et le domaine de sortie comme Output, vers lequel lesTopics vont etre rediriges. Pour la Session2 1, nous definissonsles operations dans le sens inverse, cest-a-dire les elementsnecessaires pour transferer les Topics presents dans le domaineDDS1 vers le domaine DDS0. Cette operation nous permetdonc dassurer une communication bidirectionnelle entre lesdeux domaines. De cette maniere, le pont-federe base sur leRouting Service permet alors dassurer la decouverte desentites et lechange des Topics entre deux domaines DDSdifferents.

2) Analyse de la solution dans le cas multi-domaine DDS:Pour analyser cette solution, nous nous focalisons sur la confi-guration du pont-federe comme domain-bridge illustree sur laFigure 4. En effet, Le pont-federe est lance sur le participantDDS2 pour se comporter a la fois comme consommateuret pont avec une configuration correspondant a DomainBridge avec deux domaines DDS distincts sur deux reseauxIP differents.Nous avons considere une application DDS lancee sur leparticipant DDS1 dans le domaine DDS0 qui contient unproducteur qui emet un grand nombre de messages (en DDScela correspond a un producteur du Topic Message quicontient juste une variable cle : UserID de type long etune autre variable pour le contenu du message Content detype sequence de caractere) et de lautre cote dans le domaine

1. Nest montree dans la Figure 3 pour des raisons de lespace

FIGURE 5: Deploiement de Proxies DDS dans un reseau grande distance multi-domaines IP

FIGURE 4: Test du pont-federe avec le Domain Bridge

DDS1 deux recepteurs (participant DDS2 et participant DDS3)qui se souscrivent a ce meme Topic Message.Nous avons constate que les Topics envoyes par le participantDDS1 depuis le domaine DDS0 sont recus par toutes lesmachines consommatrices (le participant DDS2 et le partici-pant DDS3) situees dans le domaine DDS1. Cependant, cetteoperation denvoi menent a la creation de deux sockets surle port 7413 et sur le port 7411 depuis la machine source(le participant DDS1) vers le pont-federe comme le montre laFigure 4. En consequence, cette solution reste partielle (memesi elle permet dacheminer le trafic DDS entre deux domainesDDS distincts se trouvant sur deux reseaux IP differents) carle flux envoye par le producteur des Topics est duplique parle nombre de machines consommatrices decouvertes par leservice Discovery de DDS.

III. LE PROXY DDS

A. Introduction

Dans la section precedente, nous avons montre que lutili-sation du service de routage de DDS dans le pont-federe nepermet pas doptimiser les flux echanges par les applicationsDDS. Dans cette section, nous proposons le proxy DDS, qui enplus fonctionnalites realisees par le pond-federe, permet dunepart la reduction le volume de trafic DDS et dautre part reponda la problematique de communication en multicast. Nousdetaillons dans la suite de cette section les services offertspar le proxy DDS ainsi que son principe de fonctionnement.

B. Services offerts par le proxy DDS

A linverse du pont-federe qui resulte dune configurationdu DDS Routing Service (DDS-RS), le proxy DDS est unesolution logicielle que nous avons implementee en C++ etindependante du DDS-RS. Ce paragraphe va detailler lesservices offerts par le proxy DDS.

1) Relier differentes applications DDS a travers un reseauWAN: Le proxy DDS permet de relier des applications DDSsituees sur des reseaux grande distance. Il relaie les mes-sages de tous les participants de son domaine IP aux autresproxies DDS du reseau. Cette configuration necessite alorsde deployer autant de proxies DDS que de domaines IP surune machine a cote du routeur de bordure. Larchitecture dedeploiement permettant dassurer la communication entre lesdifferents proxies DDS distants est montree par la Figure 5.Elle necessite de plus configurer le service de decouverte(NDDS DISCOVERY PEERS) avec toutes les adresses IPdes differents proxies.

2) Utilisation dun seul domaine DDS: Le proxy DDS estcompose de differentes entites qui communiquent dans unseul domaine DDS, mais pouvant etre dans des domaines IPdifferents. Il consomme alors tous les Topics auxquels il estabonne dans son reseau IP et retransmet les Topics destinesaux consommateurs distants vers les autres proxies DDS dis-tants respectifs. Les autres proxies DDS vont redistribuer tousces Topics recus dans leur domaine, et a travers ce mecanismetoutes les applications DDS situees dans des reseaux differentspourront partager le meme domaine DDS et considererons lereseau WAN comme support dun espace de partage global.La Figure 6 montre le deploiement de cette architecture.

C. Principe de fonctionnement du proxy DDS

Le Proxy DDS est une application qui se lance sur unemachine et sexecute explicitement comme un service DDS.Il adopte comme technologie de base le middleware DDS enutilisant les API et les services necessaires du RTI DDS. Ceproxy est compose de toutes les entites de base de DDS, etson developpement et son deploiement dependent du besoin delapplication mise en oeuvre. Cela necessite une specificationde tous les Topics echanges entre les differentes entites de lap-plication. Pour mieux comprendre le fonctionnement du proxyDDS, nous presentons les differentes etapes du deroulementsur un exemple.

Mise en place dun Proxy DDS: Nous considerons une ap-plication qui souhaite emettre un seul Topic T1 dun reseauIP a un autre a travers une connexion geree comme un seul etunique domaine DDS, et deux proxies installes a lextremite dechaque reseau. Comme le montre la Figure 7, cette applicationdispose dun producteur gere par un DataWriter de T1 etdeux consommateurs geres par deux DataReaders du memeTopic.Les etapes illustrees sur cette figure montrent le scenariodechange de donnees entre les differents participants, qui sederoule comme suit :

Etape 1 : Le producteur de lapplication publie dans lereseau local 2 des echantillons du Topic T1 en multicast.

Etape 2 : Le proxy DDS1 sinscrit au Topic T1 etconsomme tous les echantillons presents dans le do-maine DDS1 (le Subscriber de T1 consomme unique-ment les echantillons publies en multicast).

Etape 3 : A laide dune file dattente, le proxy DDS1redistribue le Topic T consomme dans le domaine DDS1en le renommant en un autre Topic T1 afin deviterque T1 soit consomme une autre fois apres avoir eteredistribue dans le domaine DDS1, et par la suite eviterune boucle locale de consommation et production desechantillons du meme Topic au niveau du Proxy DDS1.

Etape 4 : De lautre cote du reseau, un autre proxyDDS2 commence a consommer le Topic T1 des sapresence dans le domaine DDS2 (les echantillons entreles deux proxies sont echanges en Unicast puisquilssont transmis a travers le reseau WAN), ensuite lesproxies transforment T1 en T et le redistribue enmulticast dans le reseau local 1.

FIGURE 7: Interconnexion des deux proxies DDS

Etape 5 : Finalement, les consommateurs de lapplica-tion recoivent en multicast tous les echantillons publiespar le proxy de leur reseau ce qui correspond au TopicT1 envoye par le producteur de lapplication dans lereseau local 2.

IV. ETUDE DE CAS

Apres avoir decrit le principe de fonctionnement du pont-federe et du proxy DDS, nous presentons dans cette sectionune etude de cas de mise en oeuvre dune application desimulation distribuee sur DDS. Cette application consiste adevelopper une plateforme qui permet de mettre des simu-lateurs terrestres sur DDS en reseaux grande distance et departager le meme champ doperations virtuel (par exemple uneville, un aeroport, un abord de stade, etc.) et ainsi repondre aune demande de formation collective dans un environnementvirtuel le plus proche possible de la realite. Nous decrivonsla plateforme de test et les resultats experimentaux pour lavalidation de nos prototypes.

A. Plateforme de test

Une plateforme dexperimentation a ete concue et mise enplace au LAAS-CNRS. Cette plate-forme, appelee Laasnex-texp [9] et montree a la Figure 8, est independante du reseaudu LAAS et elle est raccordee directement a Renater 2, et a tra-vers Renater aux autres reseaux europeens de la recherche. Decette maniere, Laasnextexp permet de realiser des tests dans unenvironnement reel multi-technologies, multi-domaines ainsique dans un environnement emule.La plate-forme globale est composee de trois domaines avecdes adresses publiques interconnectes par le biais de plusieursequipements reseaux : trois routeurs JuniperM7i, six com-mutateurs (switches) CISCO Catalyst 2960G, 2970 et WS-C6504-E. Elle peut fonctionner en IPv4 ou IPv6 et accederaux services de multicast. Les machines qui forment la plate-forme sont des DELL PowerEdge 750, 850, 1850, 3850, 6650et 6850.

B. Evaluation du pont federe

1) Principe de Test: Afin de verifier si le volume dutrafic transmis du producteur depend du nombre de machinesreceptrices et du nombre de consommateurs dans chacune,nous avons effectue le test suivant. Ce test consiste a publier

2. http:www.renater.fr

http:www.renater.fr

FIGURE 6: Deploiement du proxy DDS sur un seul domaine DDS

FIGURE 8: Laasnetexp testbed

des Topics (les carreaux sur la Figure 9) du cote de lun desproducteurs et declarer plusieurs consommateurs de ces memeTopics. Ces consommateurs sont situes dans des reseaux IPdifferents et des domaines DDS distincts.

2) Resultats et Analyses: Les resultats de ce test sontpresentes dans la Figure 10 et la Figure 11. La Figure 10represente les flux de donnees envoyes et recus par la machineEuqos6 :

Le trafic (1) represente le flux de donnees envoyedEuqos 6 vers le pont-federe avec un debit de 20Kbpset correspond a la distribution dun seul Topic (Carreau).

Le trafic (2) represente le flux de donnees recus du pont-federe DDS avec un debit de 40Kbps et correspond a la

consommation de deux Topics (Cercle et Triangle).

La Figure 11 represente les flux de donnees envoyes et recuspar le pont-federe execute sur Euqos7 :

Le trafic (1) represente le flux de donnees recu dEuqos6qui est similaire au trafic (1) de la Figure precedente.

Le trafic (2) represente le flux de donnees envoye versEuqos6 qui est similaire aussi au trafic (2) de la Figureprecedente.

Le trafic (3) represente le flux de donnees envoyedEuqos7 vers Euqos8 avec un debit de 80Kbps etcorrespond a la distribution de deux Topics et 4 instances(3 carreaux et un cercle).

FIGURE 9: Scenario de communication du pont-federe le TopicBridge

FIGURE 10: Les flux de donnees captes sur Euqos 6

Dapres ces analyses, nous pouvons retenir que le volumede donnees envoye du domaine DDS 0 (depuis Euqos6)vers le domaine DDS 1 (Euqos7 qui contient en plus duconsommateur, le pont-federe) ne depend ni du nombre departicipants DDS locaux ni du nombre de consommateurs dansle site distant, mais juste des types de Topics envoyes. Nousremarquons aussi que le transfert des Topics dun site a unautre commence des que le pont-federe sinscrit a ces Topicet quil les duplique par la suite dans son reseau a destinationdes participants consommateurs.Nous pouvons donc constater quil est possible doptimiser levolume de donnees echangees sur les liens physiques entre desapplications DDS situees dans deux reseaux IP distants et deuxdomaines DDS differents. Cependant, le probleme est que cettesolution nest pas capable doffrir les memes performances

FIGURE 11: Flux de donnees capte par le pont-federe avec leTopic Bridge

FIGURE 12: Scenario de test du Proxy DDS

dans le cas dun seul domaine DDS. En effet, nous avonsremarque que le volume de donnees envoye dEuqos6 versEuqos7 est deux fois plus grand quand ils sont dans un seuldomaine DDS.

C. Evaluation du proxy DDS

1) Principe de Test: Pour evaluer le proxy DDS, dabordnous avons realise une application DDS distribuee qui as-sure un echange de donnees dans un seul domaine DDS.Deux Topics ont ete utilises : UserInfo et CarInfo. Coteproducteur de lapplication on considere un Publisher duTopic UserInfo et un Subscriber du Topic CarInfo, etcote client de lapplication on considere un Subscriber deUserInfo et un Publisher de CarInfo.Nous avons deploye le Proxy DDS pour mettre en reseau lap-plication de test. Ce Proxy est responsable de lechange desdeux Topics entre Euqos6 et les subscribers de lapplicationsituees dans deux reseaux distants.Le scenario utilise pour ce test est presente dans la Figure 12 :Considerons larchitecture de la plateforme LaasNetExp pource test. Le serveur de lapplication est lance sur la machine(Euqos 6) du domaine 3 et les clients sur les machines (Euqos7 et 8) du domaine 1. Par la suite, le Proxy DDS est installesur les deux reseaux (precisement sur Euqos 6 et 7).Le scenario de test consiste a lancer sur :

Euqos6 : Un Publisher de UserInfo, un Subscriber deCarInfo et le Proxy DDS1,

Euqos7 : Deux Subscribers de UserInfo et le ProxyDDS 2,

Euqos8 : Deux Subscribers de UserInfo et un Publi-sher de CarInfo

2) Resulats et Analyses: Pour analyser les resultats obtenusa partir des tests, nous nous focalisons sur la Figure 13 quiillustre les differents flux echanges : entre Euqos6 et Euqos7qui correspond au flux transmis entre les deux Proxy DDS1 et 2, le flux retransmis du Proxy DDS 1 vers Euqos8 etfinalement le flux transmis dEuqos8 vers le Proxy DDS 1.Ces flux de trafic sont presentes sur les figures 13 et 14.La Figure 13 illustre le trafic transmis entre les deux ProxyDDS distants. La courbe (1) : represente la distribution duneseule instance du Topic UserInfo envoye du proxy 1 versle proxy 2 avec un debit moyen de 15Kbps. La courbe(2) : represente la distribution dune seule instance du TopicCarInfo envoye du proxy 2 vers le proxy 1 avec un debitmoyen de 2,5Kbps.

FIGURE 13: Courbes du trafic echange entre les deux proxiesDDS

FIGURE 14: Courbes du trafic echange entre un proxy DDSet un subscriber sur EuQoS8

La Figure 14 illustre le trafic transmis en multicast dans ledomaine DDS1 entre le proxy DDS 2 et les participants DDSdans son domaine (EuQoS 7 et 8). La courbe (1) represente laredistribution du Topic UserInfo, envoye par le proxy DDS2 sur le reseau avec un debit moyen de 15Kbps. La courbe(2) represente la distribution du Topic CarInfo en multicast,envoye par Euqos 8 sur le reseau avec un debit moyen de2,5Kbps.Les resultats obtenus ont confirme que le volume de donneesenvoye par un proxy DDS (flux des Topics DDS de lappli-cation productrice), a travers le reseau dinterconnexion nedepend pas du nombre de participants DDS (subscriber), maisdepend uniquement du profil de production des Topics envoyes(Type et taille).En consequence, le proxy DDS represente une solution effi-cace pour loptimisation de la bande passante de flux dappli-cations DDS. Il permet aussi de reduire le cout du transfert dedonnees partagees dans entre plusieurs domaine DDS distinctsinterconnectes a travers un reseau multi-domaine. Commepredit, le trafic sur le reseau est reduit a sa bande passanteminimale.

V. CONCLUSION

Dans ce travail, nous avons montre quil est possible din-terconnecter des applications DDS situees sur des domainesDDS distincts en assurant leur interfonctionnement en reseauxgrande distance. Pour cela, nous avons dabord analyse lapossibilite dutiliser le service de routage que fournit la couche

middleware DDS par limplementation dun pont-federe quipermet de lier des domaines DDS distincts a travers un reseauIP multi-domaines. Ensuite, nous avons propose un proxy DDSqui en le comparant avec le pont-federe, permet doptimiserla bande passante en reduisant le trafic DDS echange enson expression minimale. Toutefois, bien que ces solutionsameliorent notre reponse a la problematique dinterfonction-nement dapplications DDS, elles noffrent quune reponseimparfaite au probleme de gestion de la QoS. Nos travauxfuturs se focaliseront sur lextension du proxy DDS vers unearchitecture de communication a QoS garantie en reseaux IPmulti-domaines.

REFERENCES[1] O. Object Management Group, Data Distribution Service for Real-Time

Systems Specification, DDSv1.2, in http://www.omg.org/spec/DDS/1.2/ ,2009.

[2] A. Corradi and L. Foschini, A DDS-compliant P2P infrastructure forreliable and QoS-enabled data dissemination, in Proceedings of the2009 IEEE International Symposium on Parallel&Distributed Processing,IPDPS 09, pp. 18, 2009.

[3] V. Lopez, M. Jose, P. Javier, and J. Lopez-Soler, DDS/SIP Interworking :A DDS-SIP Gateway, in Real-Time and Embedded Systems Workshop,May 2010.

[4] G. V. Marisol, B. V. Pablo, and E. A. Iria, Adaptive Real-Time VideoTransmission over DDS, in 8th IEEE International Conference onIndustrial Informatics (INDIN), pp. 130135, july 2010.

[5] J. Darby, M. L.S., N. Curran, and P. B. Armen, Applying Publish-Subscribe to Communications on the Move Node Control, in LincolnLaboratory Journal, vol. 16, 2007.

[6] J. Schlesselman, G. Pardo-Castellote, and B. Farabaugh, OMG DataDistribution Service (DDS) : Architectural Update, in Military Commu-nications Conference, 2004. MILCOM 2004. 2004 IEEE, vol. 2, pp. 961967, oct.-3 nov. 2004.

[7] R. T. I. RTI Innovation Inc, RTI Data Distribution Service Rou-ting Service, version 4.5c, in http://community.rti.com/content/page/documentation, 2011.

[8] R. Innovation, NDDS Middleware, 2004. RTI Innovation publish.[9] O. Philippe, Y. L. Pascal, B., and G. David, LaasNetExp : une plateforme

experimentale pour lemulation et les tests en reseaux, in ColloqueFrancophone dIngenierie des Protocoles, CFIP, 2008.

http://www.omg.org/spec/DDS/1.2/http://community.rti.com/content/page/documentationhttp://community.rti.com/content/page/documentation

IntroductionAnalyse des solutions bases sur le pont-fdrPrsentation du DDS Routing Service (DDS-RS)Solution base sur le Domain-BridgePrincipe de FonctionnementAnalyse de la solution dans le cas multi-domaine DDS

Le Proxy DDSIntroductionServices offerts par le proxy DDSRelier diffrentes applications DDS travers un rseau WANUtilisation d'un seul domaine DDS

Principe de fonctionnement du proxy DDS

Etude de casPlateforme de testEvaluation du pont fdrPrincipe de TestRsultats et Analyses

Evaluation du proxy DDSPrincipe de TestRsulats et Analyses

ConclusionRfrences