Bueno, ociando un poco me encontre (http://slyck.com/news.php?story=1073) con que le nueva version de Ares permitia transferencias entre 2 usuarios tras una NAT.
Lo unico que me imagine es que se haga con un servidor que haga de intermediante pero eso seria muy lento, así que despues leí esto (UDP hole punching (http://en.wikipedia.org/wiki/UDP_hole_punching)) en Wikipedia:
CitarAlgorithm
Let A and B be the two hosts, each in its own private network; N1 and N2 are the two NAT devices; S is a public server with a well-known globally reachable IP address.
1. A and B each begin a UDP conversation with S; the NAT devices N1 and N2 create UDP translation states and assign temporary external port numbers
2. S relays these port numbers back to A and B
3. A and B contact each others' NAT devices directly on the translated ports; the NAT devices use the previously created translation states and send the packets to A and B
Y despues leí un poco de esto (http://www.brynosaurus.com/pub/net/p2pnat/) .
Y pareciera que utiliza un servidor intermedio pero no para transferencia sino para realizar la conexión.
Bueno.. leer es una forma de entender pq' entendi muy poco de lo que decian (mucho en ingles).
Bueno, la cuestion es si alguien me puede explicar esto un poco, el 3er punto de lo que cité (que creo que es lo mas importante y justo lo que no logro entneder).
Saludos
Hola snoop,
Espero poder explicar el 3er punto de manera simple, a veeeeeer:
A sabe de B lo que S le envio (su IPinterna:PortInterno e IPpublica:Portpublico), lo mismo sabe B de A ya que S se lo envio.
De acuerdo al protocolo UDP (y a diferencia de TCP) no hay concepto de conexion (el famoso three-way-handshaking de TCP) de modo que ni bien sale un paquete, el NAT no espera por que se genere una conexion, sino que la anota inmediatamente. Sabiendo esto, A y B se empiezan a mandar paquetes uno al otro (tanto a la IP privada como la publica), si estan ambos detras del mismo NAT al enviarse mensajes a su respectiva IP privada ambas se contactan, trivial. Pero y si no estan detras de una mismo NAT? A envia un mensaje a la IP publica de B (se crea una entrada en el NAT de A), el NAT de B al no tener idea de esa conexion dropea el paquete, A sigue enviando paquetes a A, al mismo tiempo B intenta conectarse con A en su IP publica (la que S le dio) creando una entrada en el NAT de B, de este modo luego los paquetes de la conexion que esta intentando A no seran dropeados (esto es lo que llama "Hole punching" donde ambos (A y B) intentan crear un agujero).
Espero haber sido mas claro que el articulo, que de por si es bastante largo y analiza varios casos distintos.
Baii.
PS: el titulo del post no es del todo cierto, ya que no es lo mismo un NAT que un firewall, pero si es verdad que con un NAT podes hacer de firewall.
Buenisimo Predicador creo que lo entendí.
La gran pregunta es... ¿esto esta standarizado? o es como algo "al azar".. por que parece que el "hole" se crea luego de varios intentos.
Y otro punto importante, que la conexion se realiza por UDP representa una mayor programacion en la capa aplicación.
Si tenes razon lo del titulo.
Saludos,
gracias por la info
Hola snoop,
No, este no es un procedimiento standard (standard en el sentido de qe haya un RFC que hable de el) pero tampoco es azaroso.
Hay varios factores por los que puede tomar varios intentos, veamos:
Primero, hay un servdor externo que se encarga de sincronizar el lanzamiento de conexiones por A y B, pero en cierta manera no hay un reloj que sincronice A y B, por ende todo es asincronico, A y B pueden intentar conectarse con milesimas de segundo entre si (por que un paquete de datos tarda mas de S a A que de S a B) lo cual genere timeouts.
Los timeout pueden hacer que las entradas necesarias en las tablas de alguno de los NAT sean eliminadas, por ende la conexion se demorara.
Y algunas cosas mas que seguro se me escapan.
Otro problema y que vos bien resaltas es que necesita mayor programacion en la aplicacion, y esto es debido a que UDP no hace nada mas que mandar informacion, no le importa si la informacion llega o no, o si luego de enviar los paquetes 4, 5 y 6 llega 6, 4 y 5 (orden), o si hubo errores en la transmision, etc, por ende todo este trabajo de control queda para la aplicacion (omg! que overhead).
Baii