Programación de aplicaciones P2P

Conectividad P2P en pocas palabras. Supongamos que estamos hablando de UDP aquí. Los pasos a continuación también se pueden aplicar a TCP con algunos ajustes.

1. Enumere todas sus direcciones IP locales (generalmente solo 1). Cree un socket UDP en un número de puerto dado* * para cada adaptador con una dirección IP.

2. Para cada socket creado en el paso 1, póngase en contacto con un servidor STUN o TURN con ese mismo socket para descubrir su dirección IP externa y descubrir lo que mapea el número de puerto interno a fuera del NAT (no siempre es el mismo valor de puerto). Es decir, su dirección local 192.168.1.2: 4900 podría ser 128.11.12.13: 8888 al mundo exterior. Y algunos NATs no siempre usan la misma asignación de puertos cuando usan el mismo puerto local a otras direcciones IP. TURN también le proporcionará una "dirección de relé". También puede usar UPNP para obtener una dirección de puerto asignada directamente desde su enrutador, si es compatible con ese protocolo.

3. A través de un servicio de encuentro (SIP, XMPP, mensaje instantáneo, servicio web, correo electrónico, cups con cadenas), publique su lista de candidatos de direcciones en un servicio o envíe una notificación al otro cliente que diga: "Oye, quiero conectarme contigo". Este mensaje incluye todos los "candidatos de direcciones" (pares de ip y puertos) recopilados en los pasos 1 y 2.

4. El cliente remoto, al recibir la invitación para conectarse, también realiza los pasos 1 y 2 anteriores. Luego envía su lista de candidatos a través del mismo canal que recibió la lista de candidatos del invitador en.

5. Paso de perforación del agujero. Ambos clientes, comienzan a enviar mensajes de prueba a través de UDP a los candidatos de la dirección del otro lado y escuchan los mismos mensajes en su extremo. Cada vez que se reciba un mensaje, responda a la dirección de la que proviene. Eventualmente, los clientes descubrirán que tienen un par de direcciones que también pueden enviar datagramas de manera confiable. Por lo general, un extremo toma la decisión final sobre qué par de direcciones (sockets) comunicarse con y el protocolo facilita este punto final comunicándole esta decisión al otro punto final.

**- normalmente es mejor no confiar en un puerto bien conocido para clientes P2P. Porque dos clientes detrás del mismo NAT o firewall probablemente no podrían usar su software al mismo tiempo.

Aquí hay un resumen rápido de algunas tecnologías para explorar.

STUN: Es un servidor y protocolo simple para que los clientes detrás de una ruta NAT descubran cuáles son sus asignaciones de IP y puertos externos ser.

TURN es una expansión para STUN, pero admite la retransmisión para escenarios de conectividad P2P donde firewalls y NATs impiden las conexiones directas.

ICE es un conjunto de pasos mediante los cuales ATURDIR y GIRAR se utilizan para configurar una conexión P2P. ICE es un protocolo formal para los pasos 1-5 anteriores. Dos excelentes serie de diapositivas sobre HIELO son aquí y aquí.

WebRTC es una variante del estándar ICE, así como una biblioteca de referencia para haga sesiones P2P con ATURDIR y GIRAR.

UPNP + Internet Gateway Device Protocol - Algunos enrutadores admiten esto para que los hosts obtengan automáticamente asignaciones de puertos.

Libnice es una biblioteca C de código abierto para Linux (y podría funcionar en windows) que implementa ICE.

Libjingle es otra implementación de ICE (en C++) de Google. Para Windows y Linux.

PJNATH es una biblioteca dentro del conjunto de codificación PJSIP biblioteca. Es una buena implementación de una pila de HIELO (código C) y ha sido portado a muchas plataformas. (Windows, Linux, Mac, iOS, Symbian, y pronto Android).

Y finalmente, tengo un plug descarado para que uses mi código de servidor STUN base.