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 leurs serveurs.
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 peut observer sur l'image suivante:

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

Il y a plusieurs années, chaque appareil connecté chez l'utilisateur avait sa propre adresse IPv4 publique, hors IPv4 peut fournir 2^32 (4,294,967,296) adresses et avec l'évolution massive d'Internet ces adresses auraient étaient rapidement déplétées, en effet, on compte 23 milliards appareils connectés en 2018.
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 publique et en distribuant des IP privées à chaque appareil du foyer.
C'est l'apparition 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 UDP IPv4 Hole Punching

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 passent par un serveur central intermédiaire) ou décentralisé (les connexions se font directement). Dans notre cas, on considère un modèle 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.

Nous utiliserons la technique de communication par UDP & TCP Hole Punching, on a schématisé sur la figure suivante le dispositif a mettre en place:

Les deux utilisateurs parviennent à communiquer en "perçant" un tunnel et ainsi laisse le passage ouvert momentanément pour la réception d'un message.

Egalement, le serveur permet de mémoriser les ID et adresses IP des utilisateurs, et il établit un canal de contrôle de type "handshake" entre les pairs qui permet d'établir leur communication directe. Les noeuds sont en connexion constante TCP avec le serveur.

Par exemple, sur le schéma, node A envoie un message du type "je souhaite communiquer avec node B", ainsi le serveur a une connexion établie avec node B et va pouvoir lui envoyer un message avec les informations nécessaires (IP publique de node A etc...) pour que node B puisse faire une requête UDP Hole Punching vers node A.

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 recueillies 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 peuvent notamment être répondues à l'aide du peer to peer avec les technologies adaptées.

Analyse du premier concurrent

Skype

En août 2003, Skype était lancé sur une architecture peer-to-peer, décentralisée et distribuée. Pourquoi P2P? P2P offrait plusieurs avantages, notamment pour VoIP (voice over IP). En effet, Skype n'avait pas besoin de mettre en place et d'entretenir des serveurs pour le contrôle et l'envoi des données vidéos et vocales sur l'internet. Ainsi, chaque nouvel utilisateur qui se connectait au réseau représente un nœud avec sa bande passante et son infrastructure matériel, ou éventuellement un super nœud.

Le vent a commencé à tourner en 2011, lorsque Microsoft a racheté le service et l’entreprise éponyme, pour plus de 8 milliards de dollars. Le nombre d'utilisateurs a atteint 50 millions, et l'efficacité du P2P a été questionné, surtout après deux pannes très sérieuses causées par l'incapacité du réseau P2P a supporter cette situation. Le grand nombre de nœuds demandant l'accès au service nécessité de plus en plus d'algorithmes compliqués. Une autre raison a été le développement sur le marché de la téléphonie, car l'application mobile consommait bien trop de batterie, parce que les appareils doivent souvent agir comme un nœud, donc en communication constante.

Avec le temps, Microsoft a réorganisé le back-end de Skype en un service cloud sur la plate-forme Azure.

Face à ceux qui considèrent que cette transformation facilite la collecte de données, y compris par les agences gouvernementales, la firme préfère mettre en avant l’émergence de nouveaux services comme le partage de fichiers, les appels de groupe sur mobile, Skype Translator ou, plus récemment, Skype Bots.

Analyse du second concurrent

mIRC

L'IRC (Internet Relay Chat) est un protocole qui permet de dialoguer en temps réel avec d'autres utilisateurs en se connectant grâce à un logiciel spécifique (appelé un client) à un serveur IRC, lui-même relié avec d'autres serveurs IRC. Toutes les personnes ainsi connectées peuvent discuter sur des forums publics ou privés à l'aide de commandes.

C'est ce que propose mIRC, il permet de communiquer, partager, jouer ou travailler avec les autres sur des réseaux IRC autour du monde, soit en groupe de plusieurs personnes, soit en discussion privée 1 à 1. Cependant, ce système utilise des serveurs pour être fonctionnel, mais il propose un moyen pour communiquer directement avec un utilisateur qu'on appelle DCC (direct client to client), c'est une commande à taper sur le client IRC qui permet ensuite de communiquer et partager des fichiers de manière privée et sécurisée.

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

Ivan, espion Russe en mission en Ukraine, doit faire un rapport à son patron comme toutes les fins de semaines. Habituellement, il passe par une plateforme de discussion classique en utilisant des messages codés, donc cela lui importé peu que la communication soit enregistré dans un serveur quelque part sur Terre.

Cependant, cette semaine ci, les tensions se sont accentuées en Crimée entre Russie et Ukraine, et la sécurité a été amplifiée dans le pays, d'ailleurs un de ses collège a été emprisonné pour espionnage. Ainsi, pour ne prendre aucun risque, Ivan décide de changer de méthode de communication, il lui fallait un moyen plus sécurisé pour faire ses rapports.

En cherchant sur le net, il est tombé sur notre dispositif P2P. Il a donc décidé de l'utiliser et d'envoyer son rapport, mais pour cela il faut que son patron soit également enregistré sur le dispositif, il doit ainsi contacter une dernière fois son patron par le moyen habituel, mais comme il ne s'agit pas d'informations d'espionnage, il n'y a aucun risque.

Enfin, il a pu contacter son patron à travers le dispositif P2P et lui envoyer son rapport sans devoir se préoccuper d'être emprisonné.

Réponse à la question difficile

Hole Punching pour TCP ?

Oui c'est aussi possible, c'est un peu plus complexe qu'en UDP, mais c'est très similaire au niveau protocolaire. Après il est possible qu'il ne soit pas supporté par tous les NAT, mais si par chance le NAT se comporte bien, la communication P2P par TCP peut s'avérer plus robuste qu'en UDP, parce que comparé à l'UDP, la machine d'état du protocole TCP donne aux NATs sur le chemin une manière standard de déterminer précisément le temps de vie de la session TCP.

Pourquoi Skype a t-il arrêté le P2P?

De son nom originelle “Skype peer to peer” créé en 2003, a beaucoup utilisé le peer to peer jusqu’à son rachat par Microsoft en 2012. Nous allons voir en quoi Skype a été un concurrent et comment il va pouvoir nous aider dans notre projet afin de ne pas répéter les mêmes erreurs et pouvoir perdurer dans le temps en fonctionnement peer to peer.

Skype utilisait les communications UDP et du TCP entre les super nœuds.

Cependant leur protocole propriétaire fermé et non-standard permettant une bonne discrétion et augmentant la difficulté d’espionnage des communications rend leurs système très peu compatible avec les nouveaux systèmes d’exploitation et les nouveaux supports.

Skype a abandonné le P2P à cause de la trop grande utilisation de bande passante des utilisateurs faisant donc monter les factures des forfaits mobile qui étaient très chers en 2012. Skype a pour objectif de s’implanter partout et voulait remplacer les forfaits délivrant peu de communication et peu d’internet pour un coût sans limite, donc s’implanter dans la majorité des téléphones. Ils devaient donc limiter l’utilisation de bande passante. Ils utilisent maintenant le même procédé sauf que les super nœuds ne sont plus les utilisateurs mais des serveurs implantés et possédés par Skype ce qui s'apparente beaucoup plus à un réseau client serveur.

Le second problème était le problème de la batterie, un téléphone a une batterie très limitée contrairement aux PC fixes, il est donc pour eux impossible d’agir comme un nœud voir un super nœud sans réduire considérablement l’autonomie d’un téléphone. Il était donc impératif pour Microsoft de centraliser les communications et de se tourner vers un système plus standard de type client-serveur.

Qu'apporte de plus notre produit qui le rend plus original ?

Notre produit n'est pas plus original, mais il s'agit plus d'un rafraîchissement de ce qu'à réalisé Skype, notamment avec l'utilisation des IPv6, qui n'étaient pas utilisées auparavant.

Préparation du projet

Cahier des charges

Présentation:

Notre application aura pour but de créer un réseau de discussion P2P (Peer to peer) sans communiquer des messages à un tier.
Afin de mettre ceci en oeuvre nous développerons un logiciel PC et une application Android (si possible).

Fonctions à réaliser:

Enregistrer les ID utilisateurs et leur IP (IPv4 ou IPv6) sur le serveur
Envoie d’un message par la méthode Hole Punching UDP & TCP, et IPv6
Crypter les messages et décrypter à la réception

Nous devons avoir un produit le plus sécurisé, le moins énergivore possible et utiliser le moins de données internet pour application mobile.

Pour le banc de test:

mettre au point le serveur de relais (handshake)
communiquer entre deux ordinateurs avec la méthode Hole Punching UDP & TCP

Choix techniques : matériel et logiciel

Pour le banc de test:

2 routeurs CISCO ISR4221
Raspberry Pi + dongle WiFi
Câbles Ethernet
Switch

Liste des tâches à effectuer

Analyser le projet
Configurer les deux routeurs et le Pi pour simuler un réseau domestique sous NAT et un serveur
Développement du logiciel
- Hole Punching UDP IPv4
- Hole Punching TCP IPv4
- Hole Punching IPv6
- Serveur répertoire

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	Heures S11	Total
Analyse du projet	4	3	3	1									11
Banc d'essai		1	1	3	4	2	2	1					14
Développement du logiciel						4	6	10	14	18	17	14	83++
Wiki			1	1	1	2	1	3				2	11

Semaine 1

Mise en place du banc d'essai

Nous avons décidé de configurer notre réseau (routeurs + pi) localement, pour pouvoir tester notre logiciel localement, et le connecter par la suite au réseau internet pour un test à grande échelle.

Nous nous sommes donc inspiré des réseaux que l'on peut retrouver chez le particulier, c'est à dire un modem avec habituellement l'adresse IP 192.168.0.1/24, qui délivre à tous les appareils connectés du domicile une adresse IP à l'aide d'un NAT dynamique PAT par masquerade.

Ce NAT est dit dynamique car l'association entre une adresse interne et sa contrepartie externe est créée dynamiquement au moment de l'initiation de la connexion. Ce sont les numéros de ports qui vont permettre d'identifier la traduction en place : le numéro du port source (celui de la machine interne) va être modifié par le routeur. Il va s'en servir pour identifier la machine interne.

NAT dynamique PAT (Port Address Translation du port client/source) où les adresses externes sont indifférentes (le plus souvent la plage d'adresses que le fournisseur d'accès a attribuée). Le nom PAT vient du fait que le port source est modifié. Le terme masquerade est utilisé car seule l'adresse IP du routeur est utilisée comme adresse externe.

Nous avons obtenu 2 routeurs Cisco ISR4221 par M. Redon que nous avons installé dans un rack en E304. Ils seront utilisés pour notre banc d'essai, pour mettre en place la communication P2P localement pour débuter. On a commencé la configuration d'un des routeurs et on recherchera de quelle manière configurer un NAT pendant les prochaines séances.

Pour le moment, nous configurons les routeurs pour deux clients, nous n'avons pas besoin d'utiliser RIP (vu en TP) pour définir les routes vu qu'il n'y en a qu'une, ni de VLAN, on utilise les 2 interfaces présentent sur le routeur.

Configuration du premier routeur:

minicom -8 -o -b 9600 -D /dev/ttyUSB0       //connexion série pour configurer à partir d'un ordinateur

enable
no ip-domain lookup                         //désactive la recherche DNS automatique pour ne pas être embêté si on tape mal une commande 
conf t
 interface GigabitEthernet0/0/0             //interface 1
  ip address 10.0.0.1 255.255.255.0
  no shutdown
  .
 interface GigabitEthernet0/0/1             //interface 2
  ip address 192.168.0.1 255.255.255.0
  no shutdown
  .

Semaine 2

Nous continuons les recherches sur le sujet, et on débute le plan de développement de notre logiciel en langage C.

Nous avons trouvé de la documentation CISCO à propos du NAT, qu'on étudie et essaierons d'appliquer en semaine 3.

Configuration du second routeur:

enable
conf t
 interface GigabitEthernet0/0/0
  ip address 10.0.0.2 255.255.255.0
  no shutdown
  .
 interface GigabitEthernet0/1/0
  ip address 192.168.0.1 255.255.255.0
  no shutdown
  .

Semaine 3

Cette semaine on a essayé de configurer un NAT statique sur le routeur 1, nous sommes parvenu à la bonne solution après pas mal d'essais, d'ailleurs , ces essais ont rendu les configurations assez anarchique, donc nous avons reset les routeurs pour revenir à des configurations propres.

Egalement, nous avons utilisé l'utilitaire Cisco Packet Tracer pour nous aidés lors des essais et pour pouvoir simuler notre réseau lorsque nous ne sommes pas à Polytech.

L'image ci-contre permet d'avoir un aperçu du réseau que nous mettons en place pour le banc d'essai.

La config du NAT est réalisée de la sorte:

enable
 conf t
  int gigabitEthernet 0/0/0                              
   ip nat outside                                    //interface connectée à l'extérieure d'où ip nat outside
   .
  int gigabitEthernet 0/0/1
   ip nat inside                                     //interface connectée à l'intérieure d'où ip nat inside
   .
  ip nat inside source static 192.168.0.10 10.0.0.1  //translation statique, l'hôte 192.168.0.1 est accessible à l'extérieure par l'adresse fixe 10.0.0.1

Semaine 4

On termine la configuration du 2nd routeur et on teste notre réseau.

La config du routeur 2 est similaire au routeur 1, sauf pour la commande de translation qui devient:

ip nat inside source static 192.168.0.10 10.0.0.2

Maintenant, pour tester notre système, on connecte une zabeth et notre pc portable aux routeurs à l'aide de câbles Ethernet.

Il est nécessaire de configurer les adresses IP des ports Ethernet et les gateway des deux clients, et pour ne pas altérer la configuration réseau déjà présente sur la zabeth (accès internet), on utilise les commandes suivantes dans un terminal pour modifier temporairement son état:

Configuration temporaire du PC Portable (client A):

ip address add 192.168.0.10/24 dev enp0s25  //enp0s25 est le périphérique du port Ethernet du pc portable
route add default gw 192.168.0.1 enp0s25    //gateway vers le routeur

Configuration temporaire de la Zabeth (client B):

ip address add 192.168.0.10/24 dev bridge
route add default gw 192.168.0.1 dev bridge

On utilise Netcat pour simuler le Hole Punching UDP. Sur le client A on écoute sur le port 2020 et le client B émet des paquets UDP vers l'adresse 10.0.0.1 (adresse routeur 1) sur le port 2020. Si le système fonctionne, le client A doit pouvoir recevoir les messages du client B, même en présence du NAT. En effet, comme le client A indique au routeur qu'il écoute sur le port 2020, si le routeur reçoit des paquets sur ce port, il les redirigera vers le client A, ce qui équivaut à un perçage du routeur 1.

Ici, il s'avère que notre système fonctionne correctement car nous sommes parvenus à recevoir les paquets UDP sur le client A. La semaine prochaine nous commencerons la mise en place du serveur répertoire.

Semaine 5

Développement logiciel

Après une lecture approfondie des différentes documentations sur le Hole Punching, nous avons élaboré une architecture logicielle avec la définition de plusieurs fonctions que l'on fera évoluer avec le temps.

Fonctions serveur :
- Lancement du serveur
- Fonction pour accepter et lancer la fonction pour gérer les clients
- Récupérer l’@IP et le pseudo à la connexion d’un client
- Gérer les différentes commandes que le client pourra envoyer
- Initiation d’une connexion avec un client
Fonctions client :
- Lancement client + connexion serveur
- Interface proposant les requêtes possibles
- Les fonctions d’envoi des requêtes
- Création de la communication avec le "peer"
- Réponse à la demande de connexion de la part du "peer" sur demande du serveur
- Maintenir la connexion avec le correspondant (Keep alive)

Nous avons commencé le développement logiciel avec la fonction de création du serveur et une fonction pour accepter les clients et afficher les messages que le client envoie qui seront utilisés pour débuguer.

Mise en place du serveur

Le Raspberry Pi ne possède qu'un port Ethernet, on a donc eu recourt à un switch pour interconnecter les 2 routeurs et le Pi. On a juste eu à initialiser le switch et les connexions se sont réalisées automatiquement.

On a installé l'OS raspbian lite sur le Pi car nous n'avons pas besoin d'interface graphique pour héberger le serveur répertoire, et on l'a configuré en connexion série pour avoir accès à Internet et pouvoir s'y connecter en SSH par la suite grâce à la commande suivante:

ssh pi@raspberrypi.local

Pour configurer le raspberry pour le banc d'essai il suffit de taper :

ip address add 10.0.0.3/24 dev eth0

Pas besoin de configurer de route car elle n'est pas derrière un NAT.

Semaine 6

Nous avons continué le développement du logiciel avec le développement de la partie client du logiciel.

Nous avons créé les fonctions de lancement client avec connexion serveur ainsi qu'une fonction permettant d'afficher les messages reçus par le serveur et d'envoyer des messages entrés sur le terminal au serveur.

Création de deux fonctions à part prenant en paramètres un file descriptor et le message permettant d'envoyer le message sur le file descriptor ou récupérer un message en provenance du serveur. Ces deux fonctions nous servirons pour les transmissions de requêtes entre le client et le serveur.

Semaine 7

Création de la fonction de gestion des requêtes sur le client avec la requête login (trame : "Init_Pseudo!: ") implantée du côté du client et du serveur.

Cette réception de requête du côté du serveur envoie toute les informations importantes des clients vers les fonctions de Sauvegarde_client qui sont 3 fonctions regroupant une table de hachage, une fonction de sauvegarde client mémorisant le numéro de la socket client, son pseudo, son adresse IP ainsi que son port. La troisième fonction de sauvegarde client est dédiée à la déconnexion du client permettant de libérer la place et réinitialiser les données que le serveur possédait sur le client afin de ne garder aucune trace.

Nous avons mis un git en place afin de faciliter l'accès au projet.

Semaine 8

Création du serveur UDP avec la mise en place du côté client ainsi que du côté serveur la possibilité de rentrer des options :

-t ou --TCP pour lancer en TCP
-u ou --UDP pour lancer en UDP
-p ou --port suivi du port de connexion
-a suivi de l'adresse IP du serveur

Modification de plusieurs fonctions provenant du serveur TCP afin de les rendre utilisables pour le serveur UDP qu'on terminera en semaine 9. De même pour le client UDP, on espère pouvoir terminer les clients et serveurs pour pouvoir mettre en place les fonctions de Hole Punching (un client fait une requête au serveur pour communiquer avec tel client).

Semaine 9

Notre programme Hole Punching UDP a été testé sur le banc d'essai et est fonctionnel, en effet, chaque client a pu observer les paquets KeepAlive de leur pair (KeepAlive permettent de garder le port ouvert sur le NAT). On essaiera de faire une vidéo démontrant le fonctionnement de ce programme. Il faudra également mettre en place l'envoi des messages UDP entrés par l'utilisateur vers le pair car pour le moment ce ne sont que les KeepAlive qui sont envoyés. On a également fait l'acquisition d'un serveur externe sur lequel on peut héberger nos serveurs, pour pouvoir faire des tests réels. On accède au serveur avec:

ssh ibrahim@mail.garawe.tk

Comme le serveur externe est en arm64, on peut simplement lui transférer notre exécutable Serveur car il peut l'éxecuter sans problème. Le transfert s'effectue avec un simple scp.

Semaine 10

On a continué le développement du Hole Punching TCP, et ci-dessous vous pouvez voir l'arborescence de notre projet.

Pour initier la connexion en TCP entre les pairs nous allons appliquer la méthode suivante :

Tout d'abord nous avons créé un serveur de rendez-vous afin que les deux clients puissent se rejoindre, ouvrir leur port et récupérer les informations du client visé.

Une fois les deux clients connectés au serveur rendez-vous, l'un des deux clients demandera l'initialisation du protocole hole punching au serveur. Ce client sera appelé clientA.

Le serveur répondra au clientA avec l'envoi de l'adresse IP et du port du second client (appelé clientB) et utilisera en parallèle sa connexion avec le clientB pour lui envoyer un message avec les informations du clientA et l'ordre de commencer le hole punching vers le client B.

Le clientA et le clientB vont alors créer un serveur chacun sur le même port qu'ils utilisent pour communiquer avec le serveur. Ce serveur acceptera toutes les connexions entrantes, vérifiera si la connexion provient bien du peer souhaité ou le déconnectera.

En parallèle, chacun des clients créeront un client TCP qui fera des demandes de connexion (toutes les 1 secondes) sur le serveur du second client.

Ainsi, lorsque l'un des deux (le client ou le serveur) arrive à se connecter, il éteindra la communication qui n'a pas réussi à se connecter.

La communication sera alors établie entre les deux peers.

Voilà pour le côté théorique, cependant, plus on travaille sur le Hole Punching TCP, plus on rencontre de problèmes, notamment l'impossibilité de le tester sur une seule machine (le client se connecte sur son propre serveur et non pas celui de son pair), et cela rend difficile la réalisation des tests. Il est nécessaire de travailler sur plusieurs machines différentes comparé aux Hole Punching UDP. Pour le moment, les connexions échouent en boucle, nous pensons à un problème de port.

Le lien ci-dessus vous réoriente vers la vidéo de démonstration de l'UDP Hole Punching IPv4, dans cet exemple, les 2 clients sont sur la même machine, donc sous le même NAT:

Semaine 11

Cette semaine, nous reprenons l'avancement du Hole Punching TCP à commencer par le réglage de tous les ports afin de manipuler et afficher que des ports au format 'integer' et non au format 'network' afin de rendre leurs manipulations et leurs affichages simples. Cependant, nous avons aussi remarqué que le hole punching UDP ne fonctionnait plus, nous avons probablement modifié une ligne de code par erreur. Nous avons maintenant régler tous les ports et le hole punching UDP fonctionne de nouveau localement, il nous faut maintenant le tester une nouvelle fois à échelle réelle.

Nous avons aussi commencé à réfléchir pour le fonctionnement de notre programme en IPv6 mais celui ci s'avère plus compliquer que prévu, nous avons maintenant deux options, tous modifier afin d'avoir des options dans la plus part des fonctions ou refaire les fonctions qui sont spécifiques au protocole IPv4 en simplement les copiant et les adaptant en IPv6.

On s'orientera certainement vers la 2nde option.

Semaines suivantes

Tout d'abord nous avons testé à échelle réelle le Hole Punching UDP, et il fonctionne correctement, comme on peut le voir sur la vidéo suivante où les pairs sont derrière leur propre NAT:

Pour plus de contexte, seuls les points de vue d'un pair et du serveur rendez-vous sont observables, mais sur le terminal où est affiché le serveur on peut s'apercevoir de l'apparition de l'autre pair grâce à l'affichage de son endpoint.

Nous avons aussi continué le développement du Hole Punching TCP et l'avons testé localement (les pairs sur la même machine) et sur le banc d'essais et il fonctionne. Malheureusement il n'a pas fonctionné à échelle réelle.

Nous avons également terminé la réadptation du code pour IPv6/UDP, il est opérationnel à échelle réelle comme on peut le voir sur la vidéo ci-dessous: