Perforación UDP: capacidad de prueba en una sola máquina

Question

Estoy escribiendo una sencilla aplicación P2P para probar la factibilidad de utilizar la perforación UDP en un proyecto más grande.

Intenté probar mis aplicaciones desde mi casa ayer y funcionó.

Sin embargo, ahora estoy en el trabajo y el mismo código ya no hace el trabajo. El remitente está enviando al puerto apropiado en la dirección IP externa de nuestro enrutador aquí, pero el receptor no está recibiendo ninguno de ellos.

Antes de llamar al UdpClient.Receive(), la aplicación receptora envía un paquete al IP: puerto que escuchará. De nuevo, esto funciona en la configuración de mi casa, pero no aquí. El resultado es el mismo independientemente de si Windows Firewall está encendido o apagado, por lo que ese no es el problema.

¿Podría ser que los enrutadores manejen la situación de manera diferente?

EDIT1: Ambas aplicaciones se ejecutan en la misma máquina.

Answer 1

En respuesta a mi propia pregunta:

Los routers fueron de hecho que muestra un comportamiento diferente.

Mi enrutador doméstico está conectado solo a mi computadora portátil. Supongo que esta es la razón por la que cuando envío un paquete UDP desde el puerto n también deja el enrutador en el puerto n.

Sin embargo, Red de trabajo consta de varios ordenadores y el router aleatoriza el puerto en su extremo, lo que significa que un paquete enviado desde el puerto y dejará el router en el puerto x.

he conseguido con éxito mis máquinas de casa y del trabajo para comunicarse a través de NAT sin necesidad de utilizar el reenvío de puertos de la siguiente manera:

H - Envía paquetes desde el puerto de A a W: b, abriendo de esta manera el puerto A para las conexiones entrantes

W - Envía el paquete a H: a y cambia al modo de recepción. También ahora tiene un puerto abierto.

H - Recibe el paquete de W y en lugar de suponer saber a qué puerto responder, comprueba el paquete para su puerto de origen y lo utiliza en su lugar.

H - Envía paquete a W: puerto de origen

W - recibe el paquete.

Voila.

En la práctica, tho, H y W se pondrían en contacto con un servidor para intercambiar detalles de conexión, lo que simplifica porque el servidor sabe exactamente de qué puertos están enviando H y W.

Answer 2

Creo que su problema es que ambas aplicaciones se ejecutan en la misma LAN. El taladrado de orificios UDP requiere que uno de los lados tenga reenvío de puertos.

Skype utiliza man-in-the-middle si ambos lados están detrás de NAT sin ningún mapeo de puertos. Es por eso que las transferencias de archivos pueden ser tan lentas a veces.