Connexions TCP/IP directes dans les applications P2P

Question

De Post de Joel sur Copilot:

Connection directe!Nous avons toujours fait tout notre possible pour nous assurer que Fog Creek Copilot peut se connecter dans n'importe quelle situation de réseautage, quels que soient les pare-feu ou les nats.Pour y arriver, les deux parties établissent des connexions sortantes à notre serveur, qui relaie le trafic en leur nom.Eh bien, dans de nombreux cas, ce n'est pas nécessaire.La version 2.0 fait donc quelque chose de plutôt intelligent:Il configure la connexion initiale via nos serveurs, vous vous connectez donc immédiatement avec une fiabilité à 100%.Mais une fois que vous êtes tous connectés, il est tranquillement, en arrière-plan, cherche un moyen de faire une connexion directe.Si cela ne peut pas, pas grave:Vous continuez à relasser notre serveur.Si vous pouvez établir une connexion directe entre pairs, elle déplace silencieusement vos données sur la connexion directe.Vous ne remarquerez rien sauf, probablement, une communication beaucoup plus rapide.

Comment changent-ils la connexion du serveur en une connexion P2P ?

Answer 1

C'est assez délicat et intéressant.Je suis sûr que je me trompe sur certains détails, mais l'aperçu est le suivant :

Les programmes peuvent déjà communiquer entre eux via le serveur de Joel, afin qu'ils puissent échanger des informations entre eux et avec le serveur de Joel.De plus, Joel a leurs adresses IP externes et ils lui donnent des informations sur leurs adresses IP internes.

Ils décident d’essayer cette technique de perforation.L'ordinateur A initie une connexion TCP avec l'ordinateur B en utilisant l'adresse IP externe de B.Il ne passera pas, mais il indique au routeur de A qu'il doit autoriser les paquets entrants en provenance de B sur un port donné.

L'ordinateur B fait la même chose, mais son message parvient à A puisque le routeur de A a ouvert une combinaison port/IP qui correspond à ce que B a envoyé (il y a une magie de port qui se produit ici - ce n'est pas trivial, mais faisable).

Le routeur de B se souvient que B a initié une connexion avec A sur un port et une adresse IP donnés, et donc les paquets de A circulent désormais correctement vers B via leur routeur.

C'est donc en fait assez simple, mais l'implémentation contient des détails, notamment sur la manière dont les ports sont attribués aux nouvelles connexions TCP et sur la manière dont les routeurs NAT typiquement gérer les requêtes TCP et la façon dont elles sont mappées aux ports externes.Ces détails sont la partie intéressante et difficile.

-Adam

Answer 2

Il existe une technique appelée "Perforation" qui fonctionne bien avec le NAT "Cone" (Cone est une famille technique de routeur).Ce n'est pas une technique sûre à 100%, aujourd'hui, elle fonctionne bien avec UDP sur environ 80% du routeur.

Il existe quelques implémentations de bibliothèque pour réaliser le Hole Punching : ÉTOURDIR (Wikipédia)

Answer 3

Je crois que la version simple est qu'ils abandonnent la connexion au serveur et la remplacent par la connexion P2P.

Quelque chose du genre :

1. Machine1 se connecte aux serveurs du copilote.
2. Machine1 se connecte aux serveurs du copilote.
3. Machine1 se connecte aux serveurs du copilote.
4. Machine2 se connecte ensuite et ils commencent le partage d'écran.
5. Machine2 ouvre un port auquel Machine1 peut se connecter.
6. Machine1 essaie de se connecter au port désormais ouvert sur Machine2.

Si cette connexion est établie :

1. La connexion aux serveurs du copilote est coupée.
2. Les données sont plutôt transférées via la connexion directe (P2P) entre les deux machines.