LISTE DES SUJETS PFE INFORMATIQUE

الموضوع في 'أرشيف المنتدى التعليمي' بواسطة ambarca, بتاريخ ‏15 فيفري 2010.

  1. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:35
    :besmellah2:

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

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

    الملفات المرفقة:

    • P1_BANQUE.doc
      P1_BANQUE.doc
      حجم الملف:
      30,5 ك. ب
      المشاهدات:
      1.226
    • P2_BIBLIOT.doc
      P2_BIBLIOT.doc
      حجم الملف:
      44 ك. ب
      المشاهدات:
      684
    • P3_GHOTEL.doc
      P3_GHOTEL.doc
      حجم الملف:
      31,5 ك. ب
      المشاهدات:
      620
    • P4_INSCRIP.doc
      P4_INSCRIP.doc
      حجم الملف:
      30,5 ك. ب
      المشاهدات:
      621
    • P5_VOITUR.doc
      P5_VOITUR.doc
      حجم الملف:
      32,5 ك. ب
      المشاهدات:
      655
    • P6_I4_JOUET.doc
      P6_I4_JOUET.doc
      حجم الملف:
      31,5 ك. ب
      المشاهدات:
      619
    11 معجب بهذا.
  2. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:39
    et maintenant les sujets de reseaux proposés cette semestre aux universités françaises:
    ---------------------------------------------------------
    sujet 1:
    ---------------------------------------------------------
    Implémentation 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'implémenter en Java un simulateur de traceroute.
    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'en- tê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. L'idée du travail est de simuler un tel comportement sur la base d'une architecture Client/Serveur.
    Le client est considéré comme étant la source du traceroute. Il veut connaître le chemin entre lui- même et une destination. Pour ce faire, il adresse des requêtes traceroute au serveur. Ces
    requêtes 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 connaître la longueur du chemin entre lui-même
    et une destination particulière. Par longueur de chemin, nous entendons le nombre de sauts. De son côté, le serveur charge en mémoire une topologie (fichier XML ou fichier texte)
    représentant Internet. Il doit être capable d'accepter des requêtes de la part de clients. Pour chaque requête traceroute, il fournit comme réponse l'adresse (ou l'identifiant) de la machine
    (routeur intermédiaire ou destination) se situant à TTL sauts du client en direction de la destination. Pour des requêtes 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'implémenter:
    ● Un module permettant de représenter en mémoire un réseau. Des informations sur ce réseau sont fournies en entrée sous la forme d'un fichier XML ou d'un fichier texte (au choix).
    ● Un module permettant de connaître la longueur du chemin entre un client et une destination (i.e. nombre de sauts).
    ● Un module permettant de répondre à des requêtes « traceroute ». ● Le serveur utilisant ces différents modules. Le serveur doit pouvoir gérer simultanément plusieurs requêtes. Les requêtes sont transmises du client au serveur sous la forme de
    requête Java RMI ● Un exemple de client faisant des requêtes au serveur.
    Ce simulateur doit être implémenté en Java. Références
    ● Java: http://java.sun.com
    ● Java RMI: http://java.sun.com/docs/books/tutorial/rmi/index.html
     
    1 معجب بهذا
  3. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:42
    -------------------------------------------------------
    sujet 2:
    -------------------------------------------------------
    Implémentation 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, Intérêt pour IPv6
    Description
    L'objectif est d'étendre des librairies existantes afin de permettre l'exécution de traceroute dans les réseaux IPv6.
    Traceroute fonctionne comme suit: la source du traceroute, S, envoie dans le réseau des paquets (ou sondes) en incrémentant pas à pas le champs time-to-live (TTL), le TTL étant un champ de
    l'en-tê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é. 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 réseau, des paquets pour faire des traceroutes sur les réseaux IPv6.
    ● de pouvoir écouter les paquets ICMPv6 entrant. Le développement 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 développer des librairies JNI pour permettre l'interaction entre Java et le C/C++.
    Références
    ● JSocket Wrench R04: http://jswrench.sourceforge.net/ ● 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 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)
     
  4. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:43
    ----------------------------------------------------------------------------
    sujet 3:
    ----------------------------------------------------------------------------
    Implémentation d'un traceroute TCP
    Encadrant : Benoit Donnet ([email protected]) 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
     
  5. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:46
    -----------------------------------------------------------
    sujet 4:
    -----------------------------------------------------------
    Automatisation de mesures pour les réseaux ad hoc Encadrant : Jérémie Leguay Nombre d'étudiants demandés: 3
    Description générale:
    La réalisation de tests réels sur des plateformes sans-fil ad hoc s’avère souvent
    laborieuse du fait du manque d’outils appropriés. Le but de ce projet est de réaliser un outil déployant et réalisant automatiquement des scénarios de tests prédéfinis dans ce
    type d’environnement. Un scénario est défini ici par la séquence des connections à établir et par la séquence des mesures à effectuer. Après collecte des mesures effectuées, l’outil
    réalisera un rapport synthétique présentant les résultats. Pré requis :
    • Etre familier avec Linux. • Maîtrise d’un langage de script, TCSH si possible • 3 portables.
    Travail à réaliser :
    • Identification d’un ou deux outils de mesure (délai, bande passant, …). • Conception/Réalisation de l’outil. Des scripts shell seront utilisés. • Validation de l’outil sur un réseau ad hoc composé de 3 portables (prévoir
    l’installation d’un des protocoles de routage ad hoc OLSR ou AODV).
     
  6. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:47
    ------------------------------------------------------------
    sujet 5:
    ------------------------------------------------------------
    Applications ad hoc sur téléphone portable. Encadrant : Jérémie Leguay
    Nombre d'étudiants demandés : 2
    Description générale :
    Les applications devenant de plus en plus présente sur les appareils mobiles et conçues de manière décentralisée, des logiciels permettant d’échanger de l’information
    avec d’autres individus présents dans notre entourage sont tout à fait imaginable. Le but de ce projet est de se familiariser avec la plateforme J2ME, d’identifier les fonctionnalités
    de cette plateforme et de démontrer son utilisation de part le développement d’un outil de chat ad hoc entre téléphones portables équipés de la technologie Bluetooth.
    Pré requis:
    • 2 téléphones portables. • JAVA
    Travail à réaliser : • Identification des possibilités de J2ME • Conception de l’application • Développement et démonstration
     
    3 معجب بهذا.
  7. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:49
    ----------------------------------------------------------
    sujet 6
    ----------------------------------------------------------
    Sécurité des protocoles de routage ad hoc. Encadrant : Jérémie Leguay
    Nombre d'étudiants demandés : 3
    Description générale :
    De nombreux protocoles de routage pour les environnements ad hoc sans fil
    comme AODV ou OLSR ont fait l’objet d’implémentations. A l’heure actuelle aucune solution permettant de sécuriser ces protocoles vis-à-vis d’attaques comme l’injection de
    trafic de contrôle malicieux ou les dénis de service n’ont été intégré au standard RFC. Le but de ce projet est donc d’identifier des implémentations d’extensions pour ces protocoles
    assurant certaines fonctionnalités de sécurité et d’en démontrer leur bon fonctionnement.
    Pré requis : • Notions de sécurité • Etre familier avec Linux • 3 portables.
    Travail à réaliser : • Identification des extensions de sécurité implémentée • Choix de l’une d’elles et définition d’un scénario de démonstration (illustration via des attaques)
    • Mise en place de la démonstration
     
    1 معجب بهذا
  8. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:51
    ------------------------------------------------------------
    sujet 7
    ------------------------------------------------------------
    Sur l'équité des courbes de remplissage dans le partage d'espaces d'adressage
    Nombre d'étudiants demandés : 2
    Réservé pour les étudiants de la SEMAINE du 6 février (GROUPE 1)
    Encadrants : Marcelo Dias de Amorim ([email protected]) (responsable),
    Aline Carneiro Viana ([email protected]) et Yannis Viniotis ([email protected])
    Description générale L'objectif futuriste du pervasive computing, aidé par la prolifération des dispositifs de communication sans fil, conduit à un changement révolutionnaire de notre société de l'information.
    Dans ce contexte, les utilisateurs auront la possibilité d'établir d'une façon spontanée des réseaux auto organisables (SONs). Les réseaux ad hoc, les réseaux de capteurs et les réseaux maillés
    sans fil sont des exemples de réseaux auto organisables. Plus particulièrement, 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 stratégie de routage indirect basée sur DHT (table de hachage distribuée) est une proposition intéressante pour traiter le facteur d'échelle. Récemment, des
    nombreux protocoles implémentant ce type de routage et utilisant une architecture d'adressage géographique ont été proposés. Néanmoins, les modèles d'adressage et de localisation
    deviennent plus complexes à gérer dans les espaces multidimensionnels et exigent une association plus rapprochée 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 géographique indirect et un service de localisation efficace basé sur DHT. Son service de localisation est simple à gérer 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 utilisées afin de réduire un problème de
    plusieurs dimensions en un problème 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
    nœuds du réseau.
    Travail à réaliser 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 variété de courbes de remplissage a été proposée
    dans la littérature : Hilbert, Z-order et Gray-coded. Chacune de ces courbes présente différentes propriétés de localité (appelées clustering), qui affectent la gestion de l'architecture en question.
    Ainsi, les objectifs de ce projet sont :
    • Une brève étude des propriétés liées aux différentes courbes de remplissage. • L'implémentation et l'évaluation des ces propriétés dans le cas de l'architecture Twins. Plus
    spécifiquement, nous sommes intéressés par l'analyse de la distribution équitable de l'espace entre les nœuds.
    Conditions requises Les candidats doivent avoir des connaissances solides en programmation (en particulier, C ou C++).
    Références • 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.
     
    1 معجب بهذا
  9. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:53
    ----------------------------------------------------------
    sujet 8
    ----------------------------------------------------------
    Implémentation d'un service de localisation géographique
    Encadrant : Bamba Gueye
    ([email protected])
    Nombre d'étudiants demandés : 2 ou 3
    Description générale :
    Nous nous proposons de fournir un service de la localisation géographique basé sur des
    mesures de RTT faites par des serveurs sondes vers un hôte cible. La technique qui sera implémentée se base sur la multilatération qui permet d'estimer une position
    géographique en utilisant un nombre suffisant de distances à partir de quelques points mobiles (comme GPS). Pour appliquer la multilatération dans l'Internet il faut transformer
    les mesures de délai en distance géographique.
    Pour localiser un hôte, chaque serveur sonde calcule d'abord le RTT, entre lui et l'hôte cible, puis transforme ce délai en distance géographique. Ainsi chaque serveur sonde
    *S_i* (hôte référence) estime que l'hôte cible T se trouve quelque part à l'intérieur 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 région R, si elle existe, formée 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 région R. Pour ce faire, le centroide du polygone inscrit dans cette région R sera choisi comme localisation
    de l'hôte cible. Les sommets du polygone seront formés par les points d'intersection des cercles *C_iT* intérieurs à l'ensemble des cercles.
    Pré-requis : Language C
    Travail à réaliser :
    On considera comme connu la distance géographique entre les serveurs sondes et la
    cible, la localisation géographique des serveurs sondes. Il faudra implémenter:
     le processus de localisation de la cible par chaque serveur sonde.  la recherche de la région R qui représente la zone d'intersection de tous les cercles
    ayant comme  centre le serveur sonde *i* et de rayon la disatnce géographique vers la cible.  la recherche des sommets du polygone inscrit à l'intérieur de cette région R  la recherche de la localisation géographique de la cible qui sera le centroïde de ce
    polygone.
    Liens complémentaires: Pour une bonne compréhension de la méthodologie 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é déjà implémenté dans un autre langage, R, par conséquent les
    algorithmes sont disponibles.
     
    2 معجب بهذا.
  10. ambarca

    ambarca عضو فعال

    إنضم إلينا في:
    ‏24 مارس 2008
    المشاركات:
    453
    الإعجابات المتلقاة:
    473
      15-02-2010 15:56
    -----------------------------------------------------------
    sujet 9
    -----------------------------------------------------------
    Traces IPv6 Mobile

    BUT : obtenir des traces sur les échanges de messages qui apparaissent dans le cadre
    de l’utilisation d’IPv6 Mobile pour les phases de mobilité:
    - Agent Discovery
    - Enregistrement
    - Déconnexion
    - …
    Encadrante : Anne Fladenmuller, [email protected]
    Tâches :
    • Ecrire un court tutorial sur la mobilité dans IPv6 et les versions de IPv6 disponibles. • Mettre en place votre plateforme. • Définir l’architecture dont vous avez besoin pour visualiser ces échanges de trames
    et de paquets • Définir les scénarios de test.
    Architecture
    5 ordinateurs munis de deux cartes réseau connectés sur deux LAN parallèles.
    MODALITES
    Avant de débuter les projets vous devrez présenter au plus tard la semaine qui précède
    votre semaine de développements un pré-rapport spécifiant : • une architecture « minimale » de plateforme dont vous aurez besoin pour réaliser
    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 début des tests et implémentations.
    A la fin de la semaine du projet devront être rendus :
    • le rapport contenant l’ensemble des traces définies (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 différentes traces pour
    visualiser les échanges pertinents de trames.
    Ce sujet est proposé pour 1 groupe de 4 étudiants
     
    1 معجب بهذا

مشاركة هذه الصفحة