IMA4 2018/2019 P26 : Différence entre versions

De Wiki de Projets IMA
(Positionnement par rapport à l'existant)
(Analyse du premier concurrent)
Ligne 45 : Ligne 45 :
  
 
==Analyse du premier concurrent==
 
==Analyse du premier concurrent==
 +
'''Skype'''
 +
 
==Analyse du second concurrent==
 
==Analyse du second concurrent==
 
==Scénario d'usage du produit ou du concept envisagé==
 
==Scénario d'usage du produit ou du concept envisagé==

Version du 25 novembre 2018 à 21:59


Présentation générale

  • Nom du projet : Discussion pair à pair
  • Etudiants : Fabien DI NATALE & Ibrahim BEN DHIAB

Description

Sur Internet, lorsqu'on souhaite communiquer avec une personne, on passe généralement par un service de discussion instantanée qui transmet le message via leur serveur.
Mais ici, on souhaite concevoir un dispositif de communication en pair à pair c'est à dire que le message ne passe pas par un serveur tier. Ainsi, l'utilisateur devient lui-même client/serveur ou "servent" et forme des "pairs" avec les autres utilisateurs comme on observe sur l'image suivante:

Schéma de fonctionnement réseau P2P et réseau serveur

Il y a plusieurs années, les adresses IPv4 privées n'existaient pas, en effet, chaque appareil connecté chez l'utilisateur avait sa propre adresse IPv4 public, hors IPv4 peut fournir 2^32 (4,294,967,296) adresses et avec l'évolution massives d'Internet ces adresses auraient étaient rapidement déplétées.
Ce problème a été anticipé, et de nouvelles technologies ont été crées afin d'y répondre, notamment la translation d'adresse "network address translation" (NAT) ou encore l'IPv6 en 1998, qui lui peut fournir 2^128 (340,282,366,920,938,463,463,374,607,431,768,211,456) adresses. La translation d'adresse a permis de réduire l'utilisation d'adresse IPv4 considérablement, en attribuant à chaque foyer une seule adresse IPv4 public et en distribuant des IP privées à chaque appareil du foyer.
C'est l'apparitions de ces technologies et la mise en place d'IP privées qui a mis à mal le principe de pair à pair sur Internet.

Objectifs

Schéma du dispositif de communication P2P

L'objectif est de concevoir un dispositif permettant de retrouver une communication en pair à pair sans communication des messages à un tier.
Le pair à pair peut être centralisé (les connexions passe par un serveur central intermédiaire) ou décentralisé (les connexions se font directement). Dans notre cas, on souhaite un modèle décentralisé.

Plusieurs techniques peuvent être envisagées :

  • communication en IPv6 pour les utilisateurs dont les opérateurs offrent ce service ;
  • communication en Ipv4/UDP avec envoi simultané de messages pour ouvrir les ports sur les "boxes" (synchronisation par SMS ou par tier) ;
  • communication en IPv6/TCP avec contournement de la mascarade (NAT) des "boxes" par communication des numéros de séquence par tier ;
  • toute autre technique trouvée dans la littérature sur le sujet.


Pour le moment, nous choisissons la technique de communication en IPv4/UDP par UDP Hole Punching, on a schématisé sur la figure suivante le dispositif a mettre en place:

Les deux utilisateurs parviennent à communiquer en "perçant" une connexion et ainsi en laissant le passage ouvert momentanément pour la réception d'un message. Egalement, le serveur permet de sauvegarder les ID et adresses IP des utilisateurs, pour pouvoir communiquer sans devoir connaître l'IP du destinataire et il permet aussi d'établir un canal de contrôle de type "handshake" entre les pairs qui permet d'établir la communication directe entre les pairs. Ce modèle permet à l'utilisateur de ne pas configurer l'ouverture des ports de son router.
Finalement, on souhaite aussi avoir une application sous PC et Android ainsi qu'une couche de chiffrage en utilisant les clés publiques et privées.

Analyse du projet

Positionnement par rapport à l'existant

De nos jours, de plus en plus d'informations sont recueillis sur les utilisateurs sans leur accord, mais les utilisateurs recherchent :

  • l'anonymat (afin de protéger sa vie privée ou d'éviter d'éventuelles poursuites judiciaires) ;
  • le brouillage du protocole (afin d'éviter les filtrages du fournisseur d'accès internet) ;
  • le chiffrement (« on peut savoir qui je suis, mais pas ce que je télécharge »).

Ces problématiques sont répondues grâce au peer to peer.

Analyse du premier concurrent

Skype

Analyse du second concurrent

Scénario d'usage du produit ou du concept envisagé

Réponse à la question difficile

Préparation du projet

Cahier des charges

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Total
Analyse du projet 0


Prologue

Semaine 1

Semaine 2

Documents Rendus