Montar P2P descentralizada

[Kaxperday]

Buenas, siemplemente si en una red P2P todos son cliente/servidor. ¿Cómo puede funcionar, si para hacer servidor nuestro ordenador necesitamos configurar el router entre otras cosas para que se pueda producir la conexión?.

Supongamos, que realizo una conexión al tracker y de él cargo una lista de ips y su puerto de servidor de los miembros conectados a la red P2P, entonces trataría de conectarme con ellos:

Código (cpp) [Seleccionar] Expandir

connect()

Apuntando a su IP y su puerto que he descargado, sin embargo para que esto funcione ellos deben de tener un servidor escuchando y un router configurado con NAT, u otros redireccionamientos.

¿Cómo entonces es posible que haya programas P2P que funcionen sin que toquen en nada la configuración del router?, ¿no son descentralizadas esas redes P2P, o hay otro mecanismo diferente al que expuse?, estaría bien saberlo.

Un saludo, y gracias.

[engel lex]

creo que la tecnica que buscas se llama ip bashing...

supongamos que tenemos pc1 con ip 1.1.1.1 y pc2 con ip 2.2.2.2, pc1 usará el puerto 20000 para la conexión y pc2 usará el 20001, pc1 le dice al tracker que quiere conectar con pc2 por el puerto 20000, el tracker le avisa a pc2 y pc2 le avisa que tiene el 20001 preparado para esto, entonces pc1 empieza a enviar paquetes a pc2 con su ip y puerto, esto creará una ruta en el router indicando que se comunica con pc2 por el 20000 y espera que pc2 responda por 20001, pc2 hace lo mismo... allí las rutas están armadas y listas para usarse porque ambos hacen creer al router que se están comunicando con un servidor como normalmente se hace

[Kaxperday]

Gracias por la respuesta Engelx, me alegro de que haya solución.

Sin embargo apenas he visto documentación en google acerca de "ip bashing" XD.

No entiendo exactamente cual es el papel del tracker en esto, más allá de para obtener la lista de ips  online y su puerto.  Según dices "el tracker le avisa a pc2 y pc2 le avisa que tiene el puerto 20001 preparado para esto", pero eso ya lo sabría el tracker de antes en su lista tendría cargada la ip y puerto de todos los miembros online, que cargaría pc1 para conectarse con pc2 con la ip y puerto de este. No entiendo porque hay que habría que repetir ese paso.

Un saludo

[engel lex]

se repite el paso porque cada conexión con cada par se hace por un puerto diferente, ya que son dinamicos, se avisan los puertos en pro de poder levantar la ruta correctamente

[Kaxperday]

se repite el paso porque cada conexión con cada par se hace por un puerto diferente, ya que son dinamicos, se avisan los puertos en pro de poder levantar la ruta correctamente

Entonces según lo que pones:

1. pc1 se conecta al tracker y carga la lista de ip/puerto de los miembros de la red online.
2. pc1 le dice al tracker que se quiere conectar con pc2 por el puerto 10001.
3. el tracker le "avisa" a pc2. (le dice que pc1 se va a conectar a el con el 10001).
4. pc2 responde (al tracker) y dice que tiene el puerto 10002 preparado.
5. el tracker le dice a pc1 que pc2 está preparado.
5. pc1 se conecta a pc2 y ambos fueron felices y codearon perdices.

Algo no me termina de encajar ahí, y lo peor es que no encuentro documentación acerca del tema.

Saludos y gracias .

[engel lex]

tal vez me equivoco de nombre con la tecnica, no recuerdo bien XD que es lo que no te encaja?

[Kaxperday]

tal vez me equivoco de nombre con la tecnica, no recuerdo bien XD que es lo que no te encaja?

No entiendo como el tracker le debe decir a pc2 que pc1 se va a conectar con el usando su puerto 10001, y como esto puede influir en algo a la conexión final del paso 5. ¿que le importa a pc2 saber el puerto por el que se van a conectar a su servidor?... mm solo tendría sentido pasarle el puerto si pc2 pensaría que se va a conectar a un server, ¿entonces es un connect() mutuo? ¿ambos son clientes aunque creen que conectan a servidores? No sabía que era posible de ser ese el caso.

Entonces:
Se va a conectar pc1 con pc2, y simultaneamente pc2 con pc1, solo que ambos van a saber cual es su puerto con el que se conectará el otro a ellos, y ese puerto será al que apuntarán en el connect() para conectarse a ellos junto a su la ip de ellos, ¿eso ya permite la conexión?, sería:

En pc1:

Código (cpp) [Seleccionar] Expandir

connect(ip_pc2, puerto_cliente_pc2);

En pc2:

Código (cpp) [Seleccionar] Expandir

connect(ip_pc1, puerto_cliente_pc1);

Entonces ¿los 2 actuarían como cliente? Este code no puede funcionar sin un listen en el otro lado.

Saludos.

[kub0x]

Lo que buscas se llama hole punching en TCP. Hace tiempo que implementé un rendezvous que conectaba a los usuarios con solo saber su IP.

Primero debes conocer el concepto de NAT punching y los cuatro tipos de NAT: full cone, address restricted, port restricted y symmetric. Están todas bien documentadas y dependiendo de cual se use la técnica para punchear NAT cambiará, sobre todo en symmetricas.

En mi git creo que tengo papers de esto. Básicamente tu y otra máquina al enviar un SYN el router mapea la conexión, y si antes de que llegue el paquete al destino, éste envía otro SYN en vez de responder con RST dejará pasar el SYN ya que la NAT tiene una entrada en ambos extremos, espero se entienda bien.

Los protocolos encargados de obtener las IPs se llaman ICE y STUN, este último originó graan revuelo ya que podías determinar la IP se alguien tras VPN.

Saludos.

Enviado desde mi G630-U20 mediante Tapatalk

[Kaxperday]

Wuuu muchas gracias, es lo que buscaba. Ya me documentaré más acerca del tema.

Lo que me pregunto ahora es de donde aprendes esas cosas XD.

Saludos socio

[engel lex]

Lo que me pregunto ahora es de donde aprendes esas cosas XD.

si conoces bien el protocolo y como funciona el nat es facil darse cuenta que es la forma de