UDP perforazione non in corso su 3G

Question

Sto cercando di implementare in un software una funzionalità di perforazione. Il fatto è che sto implementando questo con un server TCP già creato per comunicare con gli utenti.

Ecco quello che ho finora:

• "A" invia un messaggio a un server UDP "US" (sulla porta 9333)
• "USA" rimanda a "A" la porta è ha collegato (porta 31000 - localport 31005)
• "A" invia un messaggio a un server TCP "TS" dicendo che vuole connettersi a B (e fornire la porta 31000)
• "TS" invia un messaggio a "B" assegnandogli la porta "A" (31000) e ip
• "B" invia un messaggio e per "US" (sulla porta 9333)
• "US" invia un messaggio a "B" gli diceva il suo 45000 porta (localport 45005)
• "B" invia un messaggio a "TS" dare è la porta UDP (45000)
• "TS" invia un messaggio a "a" dare porto di B UDP (45000) e ip
• "a" iniziare a inviare un messaggio UDP IP di B sulla porta 45000 e ascoltare localport 31005
• "B "inizia a inviare il messaggio udp a A ip sulla porta 31000 e ascolta su localport 45005

Ovviamente porte 31000, 31005, 45000 e 45005 sono qui per esempio, ogni nuova connessione cambia la porta, solo 9333 è statico.

So che c'è un sacco di avanti e indietro, più di quanto dovrebbe essere. Il fatto è che sono obbligato ad utilizzare il server TCP per comunicare con entrambi gli utenti, il server udp è qui solo per restituire la porta User a se stesso in modo che possa inviarlo nuovamente al server TCP.

Tuttavia i messaggi tra gli utenti non vengono ricevuti da nessuno ... Qualcuno avrebbe un'idea del perché?

---

EDIT:

Ho testato il mio router con http://nattest.net.in.tum.de/test.php e UDP perforazione funziona bene, in modo che il problema non è venuta dal mio router, ma dal mio protocollo ...

Quando gli utenti sono dietro lo stesso NAT, tutto funziona bene, ovviamente utilizza IP privato, ma significa che il codice funziona anche, quindi ogni volta porta a un problema di protocollo ...

---

EDIT 2:

In realtà, mi ha reso la metà lavoro (e il problema veniva dal mio codice in realtà, non è il protocollo ... Ho collegato 2 utenti, uno in 3G con un iPhone, uno dietro il mio NAT su Wifi.

La cosa divertente (beh, non tanto) è, solo un socket è stato in grado di ricevere e inviare dati tra entrambi gli utenti. (la presa avviata dall'iphone) Secondo il protocollo dovrei avere 2 prese ben collegate, ho sbagliato?

Quindi sono riuscito a eseguire un buco nel mio NAT, ma in realtà non nel NAT cellulare.

Ovviamente, ho testato subito 2 iPhone connessi in 3G. E nessuno ottiene il messaggio dall'altro.

Mi sono perso qualcosa sul NAT cellulare?

P.S. : Ci scusiamo per l'aggiornamento così tanto la mia domanda, ma poiché non ottengo risposta sto cercando di trovare da solo ...

P.S. 2: Dal momento che sono riuscito a fare un buco nel mio NAT, ho cambiato il titolo aggiungendo "il 3G"

---

EDIT 3: ho eseguito nuovamente il test http://nattest.net.in.tum.de/test.php con il mio computer collegato ad internet tramite il mio iPhone di Connessione 3G.

Ecco il risultato:

A quanto pare tutti UDP prova perforazione hanno avuto successo il 9 di prova.

ulteriormente più sembra:

UDP Binding Test (?): Endpoint, la previsione porta vincolante indipendente è facile

quindi non dovrebbe essere alcun problema di collegamento 2 peers su reti 3G di connessione (anche non molto oltre dietro una "casa" NAT) ... Ho ragione?

---

EDIT 4:

Giusto per essere sicuri, ora mando un messaggio a due distinte UDP server, per verificare se la porta e la porta locale sono gli stessi su 3G.

Per farla breve, le porte (locale e pubblica) sono le stesse quando ci si connette su entrambi i server. quindi il test fatto su EDIT 2 era corretto, udp è indipendente dall'endpoint, quindi non ci dovrebbero essere problemi nel forare il foro immagino ... (Almeno con il mio ISP)

Answer 1

Sfortunatamente, non esiste un affidabile al 100% modo per eseguire la perforazione NAT con UDP. Nella migliore delle ipotesi, puoi fare qualche ipotesi su come i NAT e i firewall si comportano probabilmente la maggior parte del tempo. Ma ci saranno sempre delle eccezioni e potrebbero non essere rari.

In questo caso, sembra che si stia utilizzando un server centrale per consentire a due peer di individuare le altre porte esterne e quindi iniziare a inviare i dati reciprocamente. Questo è un algoritmo piuttosto buono. Il problema è che il routing della porta esterna può variare a seconda della destinazione. In altre parole, se A a B ha una porta esterna di 5000, non vi è alcuna garanzia che A a C arriverà anche da 5000. Quindi, avendo un server centrale, registrare la porta che vede potrebbe non aiutare a connettere qualcun altro.

Ecco alcune domande correlate con ulteriori dettagli.

• UDP Hole Punching Algorithm
• UDP Hole Punching not possible with mobile provider
• UDP hole punching host-specific failure

Answer 2

Il NAT sei dietro è simmetrica, o cambia il numero di porta in uscita a seconda della destinazione. La perforatura attraverso il NAT simmetrico richiede un metodo diverso (punzonatura multi-foro TURN o UDP). Prova a farlo in questo modo: https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing