> > >


 
15-02-2010, 14:35 : 1
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute

LISTE DES SUJETS PFE INFORMATIQUE



pour les etudiants d'informatique, je propose pour mes chers collegues une liste des sujets de PFE reseaux et BD


on commance par les sujets de BD
(necessite un stage)






.
exe !
 : doc P1_BANQUE.doc (30,5 , 1158)
 : doc P2_BIBLIOT.doc (44,0 , 653)
 : doc P3_GHOTEL.doc (31,5 , 586)
 : doc P4_INSCRIP.doc (30,5 , 587)
 : doc P5_VOITUR.doc (32,5 , 623)
 : doc P6_I4_JOUET.doc (31,5 , 586)
15-02-2010, 14:39 : 2
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


et maintenant les sujets de reseaux proposs cette semestre aux universits franaises:
---------------------------------------------------------
sujet 1:
---------------------------------------------------------
Implmentation d'un simulateur de traceroute. Encadrant : Benoit Donnet (benoit.donnet@lip6)
Nombre d'Etudiants : Au moins 2.
Pr-Requis : Rigueur, Java, Java RMI
Description L'objectif du travail est d'implmenter en Java un simulateur de traceroute.
Traceroute est un outil rseau qui permet de dcouvrir le chemin qu'un paquet de donnes prend
pour aller d'une machine S (la source ou moniteur) vers une machine D (la destination). Traceroute fonctionne comme suit: la source du traceroute, S, envoie dans le rseau des paquets
(ou sondes) en incrmentant pas pas le champ time-to-live (TTL), le TTL tant un champ de l'en- tte du paquet IP. Le TTL a pour but d'indiquer combien de temps un paquet peut circuler dans le
rseau. Chaque fois qu'un paquet entre dans un routeur, le routeur dcrmente le TTL. Quand le TTL vaut 1, le routeur dtermine que le paquet a consomm suffisamment de ressources dans le
rseau, le jette et informe la source du paquet de l'incident en renvoyant un message ICMP time exceeded. En regardant l'adresse IP source du message ICMP, le moniteur peut apprendre
l'adresse du routeur qui a jet le paquet. L'ide du travail est de simuler un tel comportement sur la base d'une architecture Client/Serveur.
Le client est considr comme tant la source du traceroute. Il veut connatre le chemin entre lui- mme et une destination. Pour ce faire, il adresse des requtes traceroute au serveur. Ces
requtes comprennent trois informations: ● l'adresse (ou l'identifiant) du client ● l'adresse (ou l'identifiant) de la destination ● la valeur du TTL. A noter aussi que le client peut vouloir simplement connatre la longueur du chemin entre lui-mme
et une destination particulire. Par longueur de chemin, nous entendons le nombre de sauts. De son ct, le serveur charge en mmoire une topologie (fichier XML ou fichier texte)
reprsentant Internet. Il doit tre capable d'accepter des requtes de la part de clients. Pour chaque requte traceroute, il fournit comme rponse l'adresse (ou l'identifiant) de la machine
(routeur intermdiaire ou destination) se situant TTL sauts du client en direction de la destination. Pour des requtes sur la longueur du chemin, il renvoie simplement le nombre de sauts entre le
client et la destination. Dans ce travail, il est demand d'implmenter:
● Un module permettant de reprsenter en mmoire un rseau. Des informations sur ce rseau sont fournies en entre sous la forme d'un fichier XML ou d'un fichier texte (au choix).
● Un module permettant de connatre la longueur du chemin entre un client et une destination (i.e. nombre de sauts).
● Un module permettant de rpondre des requtes traceroute . ● Le serveur utilisant ces diffrents modules. Le serveur doit pouvoir grer simultanment plusieurs requtes. Les requtes sont transmises du client au serveur sous la forme de
requte Java RMI ● Un exemple de client faisant des requtes au serveur.
Ce simulateur doit tre implment en Java. Rfrences
● Java: http://java.sun.com
● Java RMI: http://java.sun.com/docs/books/tutorial/rmi/index.html






ambarca
15-02-2010, 14:42 : 3
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


-------------------------------------------------------
sujet 2:
-------------------------------------------------------
Implmentation de librairies pour un traceroute IPv6.
Encadrant Benoit Donnet (benoit.donnet@lip6) Nombre d'Etudiants : Au moins 2.
Pr-Requis : Rigueur, Java, C/C++, Java JNI, Intrt pour IPv6
Description
L'objectif est d'tendre des librairies existantes afin de permettre l'excution de traceroute dans les rseaux IPv6.
Traceroute fonctionne comme suit: la source du traceroute, S, envoie dans le rseau des paquets (ou sondes) en incrmentant pas pas le champs time-to-live (TTL), le TTL tant un champ de
l'en-tte du paquet IP. Le TTL a pour but d'indiquer combien de temps un paquet peut circuler dans le rseau. Chaque fois qu'un paquet entre dans un routeur, le routeur dcrmente le TTL.
Quand le TTL vaut 1, le routeur dtermine que le paquet a consomm suffisamment de ressources dans le rseau, le jette et informe la source du paquet de l'incident en renvoyant un message
ICMP time exceeded. En regardant l'adresse IP source du message ICMP, le moniteur peut apprendre l'adresse du routeur qui a jet le paquet.
Que se passe-t-il quand la sonde atteint finalement la destination? En fait, le comportement de la destination dpend du type de sonde qui est envoy par la source. Typiquement, traceroute peut
en utiliser trois types diffrents (au choix): ● UDP. Il s'agit d'un traceroute classique. Les sondes sont des paquets UDP avec un numro de port lev (i.e. suprieur 1024). Quand le paquet UDP arrive la destination,
celle-i est suppose rpondre avec un message ICMP destination unreachable. Le fait de mettre un numro de port lev offre une certaine probabilit qu'aucune application n'coute
sur ce port la destination, ce qui gnrera un message ICMP destination unreachable. ● ICMP. Les sondes envoyes par la source sont des messages ICMP echo request. La destination est suppose rpondre avec des messages echo reply.
● TCP. Les sondes envoyes sont des paquets TCP avec le flag SYN mis 1. La destination est suppose rpondre avec des paquets TCP dont le flag SYN_ACK est mis 1.
L'avantage du traceroute TCP est qu'il permet de passer outre la plupart des filtres de firewall. Le traceroute TCP suppose que les firewalls vont laisser entrer les paquets TCP si
la destination coute sur le port spcifi. Il existe un projet open-source, JSocket Wrench, qui permet d'effectuer des traceroutes en Java.
Malheureusement, les librairies fournies par JSocket Wrench ne concernent que IPv4. Il est demand, dans ce travail, d'tendre JSocket Wrench afin
● de pouvoir manipuler des paquets IPv6. ● de pouvoir manipuler des paquets ICMPv6. ● de pouvoir envoyer, dans le rseau, des paquets pour faire des traceroutes sur les rseaux IPv6.
● de pouvoir couter les paquets ICMPv6 entrant. Le dveloppement des librairies se fera principalement en Java. La manipulation des sockets fera
appel des commandes C/C++. Il n'est donc pas exclu de devoir dvelopper des librairies JNI pour permettre l'interaction entre Java et le C/C++.
Rfrences
● JSocket Wrench R04: http://jswrench.sourceforge.net/ ● Aide sur l'implmentation de traceroute: http://cities.lk.net/trproto.html ● IP protocols et format des paquets: http://www.networksorcery.com/enp/topic/ipsuite.htm ● RFC 768: User Datagram Protocol (http://www.ietf.org/rfc/rfc768.txt) ● RFC 793: Transmission Control Protocl (http://www.ietf.org/rfc/rfc792.txt) ● RFC 1883: Internet Protocol Version 6 (http://www.ietf.org/rfc/rfc1883.txt) ● RFC 1885: Internet Control Message Protocol Version 6 (http://www.ietf.org/rfc/rfc1885.txt)






15-02-2010, 14:43 : 4
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


----------------------------------------------------------------------------
sujet 3:
----------------------------------------------------------------------------
Implémentation d'un traceroute TCP
Encadrant : Benoit Donnet (benoit.donnet@lip6.fr) Nombre d'Etudiants : Au moins 2.
Pré-Requis Connaissance en C/C++, Intérêt pour l'implémentation, Rigueur
Description
L'objectif du travail est d'implémenter en C/C++ un traceroute basé sur des paquets TCP.
Traceroute est un outil réseau qui permet de découvrir le chemin qu'un paquet de données prend
pour aller d'une machine S (la source ou moniteur) vers une machine D (la destination).
Traceroute fonctionne comme suit: la source du traceroute, S, envoie dans le réseau des paquets (ou sondes) en incrémentant pas à pas le champ time-to-live (TTL), le TTL étant un champ de l'entête
du paquet IP. Le TTL a pour but d'indiquer combien de temps un paquet peut circuler dans le réseau. Chaque fois qu'un paquet entre dans un routeur, le routeur décrémente le TTL. Quand le
TTL vaut 1, le routeur détermine que le paquet a consommé suffisamment de ressources dans le réseau, le jette et informe la source du paquet de l'incident en renvoyant un message ICMP time
exceeded. En regardant l'adresse IP source du message ICMP, le moniteur peut apprendre l'adresse du routeur qui a jeté le paquet.
Que se passe-t-il quand la sonde atteint finalement la destination? En fait, le comportement de la
destination dépend du type de sonde qui est envoyé par la source. Typiquement, traceroute peut en utiliser trois types différents (au choix):
● UDP. Il s'agit d'un traceroute “classique”. Les sondes sont des paquets UDP avec un numéro de port élevé (i.e. supérieur à 1024). Quand le paquet UDP arrive à la destination,
celle-çi est supposée répondre avec un message ICMP destination unreachable. Le fait de mettre un numéro de port élevé offre une certaine probabilité qu'aucune application n'écoute
sur ce port à la destination, ce qui générera un message ICMP destination unreachable. ● ICMP. Les sondes envoyées par la source sont des messages ICMP echo request. La destination est supposée répondre avec des messages echo reply.
● TCP. Les sondes envoyées sont des paquets TCP avec le flag SYN mis à 1. La destination est supposée répondre avec des paquets TCP dont le flag SYN_ACK est mis à 1.
L'avantage du traceroute TCP est qu'il permet de passer outre la plupart des filtres de firewall. Le traceroute TCP suppose que les firewalls vont laisser entrer les paquets TCP si
la destination écoute sur le port spécifié.
Cependant, le comportement décrit plus haut est le cas idéal du traceroute. Un routeur le long du chemin peut ne pas répondre aux sondes pour différentes raisons. Par exemple, le protocole
ICMP est désactivé dans le routeur ou bien il est surchargé. Afin d'éviter que la source n'attende un temps infini la réponse ICMP du routeur, la source active un temporisateur lors du lancement
de la sonde. A l'expiration de ce timer, si aucun message ICMP n'a été reçu, alors, pour le TTL considéré, le routeur est étiqueté non-répondant.
Cependant, un problème survient quand c'est la destination qui ne répond pas aux sondes. Dans
ce cas, la destination sera enregistrée comme non-répondante mais il est impossible de savoir si elle a été atteinte. Afin d'éviter d'inférer un chemin sans fin, une borne supérieure sur le nombre
de machines non-répondante successives est utilisé. Une valeur typique pour cette borne est 5.
Dans ce travail, il est demandé d'implémenter une version particulière du traceroute TCP. Un des gros problèmes de traceroute est sa lenteur. A chaque TTL, la source envoie trois sondes et
attend pour une éventuelle réponse. On peut augmenter la vitesse d'exécution du traceroute si on connait la longueur du chemin. En effet, si on a connaissance du nombre de routeurs
intermédiaires le long du chemin entre la source et la destination, on peut envoyer « en même
s. Si on n'arrive pas à connaître la longueur du chemin, alors on effectue un traceroute « classique », i.e. TTL par TTL.
Il est donc demandé d'implémenter:
● un module permettant de connaître la longueur du chemin entre la source du traceroute et la destination
● un module permettant d'envoyer simultanément plusieurs paquets dans le réseau, quelque soit le type de paquet (TCP, UDP, ICMP)
● un module permettant de construire des paquets TCP pour le traceroute TCP ● un module permettant d'écouter les paquets entrant (ICMP et TCP). ● une application utilisant ces différents modules.
Il est demandé d'implémenter cet outil en C/C++. Pour d'évidentes raisons de simplicité (polymorphisme, héritage, ...), il est conseillé d'utiliser un maximum le C++.
Références
● Aide sur l'implémentation de traceroute: http://cities.lk.net/trproto.html
● IP protocols et format des paquets: http://www.networksorcery.com/enp/topic/ipsuite.htm ● RFC 791: Internet Protocol (http://www.ietf.org/rfc/rfc0791.txt) ● RFC 768: User Datagram Protocol (http://www.ietf.org/rfc/rfc768.txt) ● RFC 792: Internet Control Message Protocol (http://www.ietf.org/rfc/rfc792.txt) ● RFC 793: Transmission Control Protocl (http://www.ietf.org/rfc/rfc792






15-02-2010, 14:46 : 5
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


-----------------------------------------------------------
sujet 4:
-----------------------------------------------------------
Automatisation de mesures pour les rseaux ad hoc Encadrant : Jrmie Leguay Nombre d'tudiants demands: 3
Description gnrale:
La ralisation de tests rels sur des plateformes sans-fil ad hoc savre souvent
laborieuse du fait du manque doutils appropris. Le but de ce projet est de raliser un outil dployant et ralisant automatiquement des scnarios de tests prdfinis dans ce
type denvironnement. Un scnario est dfini ici par la squence des connections tablir et par la squence des mesures effectuer. Aprs collecte des mesures effectues, loutil
ralisera un rapport synthtique prsentant les rsultats. Pr requis :
Etre familier avec Linux. Matrise dun langage de script, TCSH si possible 3 portables.
Travail raliser :
Identification dun ou deux outils de mesure (dlai, bande passant, ). Conception/Ralisation de loutil. Des scripts shell seront utiliss. Validation de loutil sur un rseau ad hoc compos de 3 portables (prvoir
linstallation dun des protocoles de routage ad hoc OLSR ou AODV).






15-02-2010, 14:47 : 6
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


------------------------------------------------------------
sujet 5:
------------------------------------------------------------
Applications ad hoc sur tlphone portable. Encadrant : Jrmie Leguay
Nombre d'tudiants demands : 2
Description gnrale :
Les applications devenant de plus en plus prsente sur les appareils mobiles et conues de manire dcentralise, des logiciels permettant dchanger de linformation
avec dautres individus prsents dans notre entourage sont tout fait imaginable. Le but de ce projet est de se familiariser avec la plateforme J2ME, didentifier les fonctionnalits
de cette plateforme et de dmontrer son utilisation de part le dveloppement dun outil de chat ad hoc entre tlphones portables quips de la technologie Bluetooth.
Pr requis:
2 tlphones portables. JAVA
Travail raliser : Identification des possibilits de J2ME Conception de lapplication Dveloppement et dmonstration






15-02-2010, 14:49 : 7
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


----------------------------------------------------------
sujet 6
----------------------------------------------------------
Scurit des protocoles de routage ad hoc. Encadrant : Jrmie Leguay
Nombre d'tudiants demands : 3
Description gnrale :
De nombreux protocoles de routage pour les environnements ad hoc sans fil
comme AODV ou OLSR ont fait lobjet dimplmentations. A lheure actuelle aucune solution permettant de scuriser ces protocoles vis--vis dattaques comme linjection de
trafic de contrle malicieux ou les dnis de service nont t intgr au standard RFC. Le but de ce projet est donc didentifier des implmentations dextensions pour ces protocoles
assurant certaines fonctionnalits de scurit et den dmontrer leur bon fonctionnement.
Pr requis : Notions de scurit Etre familier avec Linux 3 portables.
Travail raliser : Identification des extensions de scurit implmente Choix de lune delles et dfinition dun scnario de dmonstration (illustration via des attaques)
Mise en place de la dmonstration






ambarca
15-02-2010, 14:51 : 8
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


------------------------------------------------------------
sujet 7
------------------------------------------------------------
Sur l'quit des courbes de remplissage dans le partage d'espaces d'adressage
Nombre d'tudiants demands : 2
Rserv pour les tudiants de la SEMAINE du 6 fvrier (GROUPE 1)
Encadrants : Marcelo Dias de Amorim (marcelo.amorim@lip6.fr) (responsable),
Aline Carneiro Viana (aline.viana@irisa.fr) et Yannis Viniotis (candice@ncsu.edu)
Description gnrale L'objectif futuriste du pervasive computing, aid par la prolifration des dispositifs de communication sans fil, conduit un changement rvolutionnaire de notre socit de l'information.
Dans ce contexte, les utilisateurs auront la possibilit d'tablir d'une faon spontane des rseaux auto organisables (SONs). Les rseaux ad hoc, les rseaux de capteurs et les rseaux maills
sans fil sont des exemples de rseaux auto organisables. Plus particulirement, le routage large chelle dans les SONs constitue un vrai challenge en raison de la dynamique de la topologie et du
manque d'infrastructure fixe. La stratgie de routage indirect base sur DHT (table de hachage distribue) est une proposition intressante pour traiter le facteur d'chelle. Rcemment, des
nombreux protocoles implmentant ce type de routage et utilisant une architecture d'adressage gographique ont t proposs. Nanmoins, les modles d'adressage et de localisation
deviennent plus complexes grer dans les espaces multidimensionnels et exigent une association plus rapproche entre les plans physique et logique. Dans ce contexte, le protocole
Twins a t propos.
Twins est une nouvelle architecture qui met en place un routage gographique indirect et un service de localisation efficace bas sur DHT. Son service de localisation est simple grer en
raison de l'utilisation d'un espace unidimensionnel pour sa mise en place. Dans Twins, l'quivalence entre l'espace multidimensionnel, employ pour le routage, et l'espace
unidimensionnel, utilis pour la localisation, est obtenue par le biais de l'utilisation des courbes de remplissage d'espace. Les courbes de remplissage sont utilises afin de rduire un problme de
plusieurs dimensions en un problme d'une seule dimension : une ligne qui connecte tous les points de l'espace. Cette ligne simplifie la gestion de l'espace et rend facile son partage entre les
nuds du rseau.
Travail raliser Le sujet principal de ce projet reposera sur l'analyse des courbes de remplissage d'espace dans le contexte de l'architecture Twins. Une large varit de courbes de remplissage a t propose
dans la littrature : Hilbert, Z-order et Gray-coded. Chacune de ces courbes prsente diffrentes proprits de localit (appeles clustering), qui affectent la gestion de l'architecture en question.
Ainsi, les objectifs de ce projet sont :
Une brve tude des proprits lies aux diffrentes courbes de remplissage. L'implmentation et l'valuation des ces proprits dans le cas de l'architecture Twins. Plus
spcifiquement, nous sommes intresss par l'analyse de la distribution quitable de l'espace entre les nuds.
Conditions requises Les candidats doivent avoir des connaissances solides en programmation (en particulier, C ou C++).
Rfrences A. C. Viana, M. D. de Amorim, Y. Viniotis, S. Fdida, and J. F. de Rezende, Twins: A Dual
Addressing Space Representation for Self-Organizing Networks, to appear in IEEE Transactions on Parallel and Distributed Systems, December 2006.
A. C. Viana, M. D. de Amorim, Y. Viniotis, S. Fdida, and J. F. de Rezende, Easily- managed and topological-independent location service for self-organizing networks, ACM
MobiHoc, Urbana-Champaign, IL, May 2005.






ambarca
15-02-2010, 14:53 : 9
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


----------------------------------------------------------
sujet 8
----------------------------------------------------------
Implmentation d'un service de localisation gographique
Encadrant : Bamba Gueye
(bamba.gueye@lip6.fr)
Nombre d'tudiants demands : 2 ou 3
Description gnrale :
Nous nous proposons de fournir un service de la localisation gographique bas sur des
mesures de RTT faites par des serveurs sondes vers un hte cible. La technique qui sera implmente se base sur la multilatration qui permet d'estimer une position
gographique en utilisant un nombre suffisant de distances partir de quelques points mobiles (comme GPS). Pour appliquer la multilatration dans l'Internet il faut transformer
les mesures de dlai en distance gographique.
Pour localiser un hte, chaque serveur sonde calcule d'abord le RTT, entre lui et l'hte cible, puis transforme ce dlai en distance gographique. Ainsi chaque serveur sonde
*S_i* (hte rfrence) estime que l'hte cible T se trouve quelque part l'intrieur du cercle *C_iT* centr en *S_i* et de rayon *R_iT*. Par exemple si nous avons K serveurs
sondes, nous avons C_T ={ C_1T, C_2T, ... , C_KT** cercles. L'unique rgion R, si elle existe, forme par l'intersection de l'ensemble des cercles C_iT C_T contient
l'estimation de localisation de la cible.
Pour trouver l'estimation de localisation de la cible T, il faudra estimer la rgion R. Pour ce faire, le centroide du polygone inscrit dans cette rgion R sera choisi comme localisation
de l'hte cible. Les sommets du polygone seront forms par les points d'intersection des cercles *C_iT* intrieurs l'ensemble des cercles.
Pr-requis : Language C
Travail raliser :
On considera comme connu la distance gographique entre les serveurs sondes et la
cible, la localisation gographique des serveurs sondes. Il faudra implmenter:
 le processus de localisation de la cible par chaque serveur sonde.  la recherche de la rgion R qui reprsente la zone d'intersection de tous les cercles
ayant comme  centre le serveur sonde *i* et de rayon la disatnce gographique vers la cible.  la recherche des sommets du polygone inscrit l'intrieur de cette rgion R  la recherche de la localisation gographique de la cible qui sera le centrode de ce
polygone.
Liens complmentaires: Pour une bonne comprhension de la mthodologie vous pourriez visiter les liens cidessous:
http://rp.lip6.fr/~gueye/articles/ToN_CBG.pdf (plus complet)
http://rp.lip6.fr/~gueye/articles/CFIP05.pdf Ce service a t dj implment dans un autre langage, R, par consquent les
algorithmes sont disponibles.






2 ambarca
15-02-2010, 14:56 : 10
ambarca
ambarca

  ambarca





ambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond reputeambarca has a reputation beyond repute


-----------------------------------------------------------
sujet 9
-----------------------------------------------------------
Traces IPv6 Mobile

BUT : obtenir des traces sur les changes de messages qui apparaissent dans le cadre
de lutilisation dIPv6 Mobile pour les phases de mobilit:
- Agent Discovery
- Enregistrement
- Dconnexion
-
Encadrante : Anne Fladenmuller, Anne.Fladenmuller@lip6.fr
Tches :
Ecrire un court tutorial sur la mobilit dans IPv6 et les versions de IPv6 disponibles. Mettre en place votre plateforme. Dfinir larchitecture dont vous avez besoin pour visualiser ces changes de trames
et de paquets Dfinir les scnarios de test.
Architecture
5 ordinateurs munis de deux cartes rseau connects sur deux LAN parallles.
MODALITES
Avant de dbuter les projets vous devrez prsenter au plus tard la semaine qui prcde
votre semaine de dveloppements un pr-rapport spcifiant : une architecture minimale de plateforme dont vous aurez besoin pour raliser
ces tests. Les changes de trames ou paquets que vous voudrez mettre en vidence pendant le projet.
Le tutorial.
Ce pr rapport devra tre valid avant le dbut des tests et implmentations.
A la fin de la semaine du projet devront tre rendus :
le rapport contenant lensemble des traces dfinies (pr-rapport).
une version des traces, ceci permettant de visualiser avec Ethereal les changes
de trames/paquets/datagrammes. Une explication des filtres appliquer Ethereal sur les diffrentes traces pour
visualiser les changes pertinents de trames.
Ce sujet est propos pour 1 groupe de 4 tudiants






ambarca

:







:01:56 GMT +1.

* *