Io lavoro su middleware open source per sistemi multi-agente e di recente abbiamo creato un'opzione di trasporto basata su UDP per l'utilizzo di p2p su reti 4G/3G. Lo abbiamo testato sui piani dati di T Mobile e su varie reti accademiche dietro NAT, e al momento mi sento abbastanza fiducioso nell'implementazione. Poiché non sembrano esserci soluzioni solide a questa domanda, ho pensato di condividere il tipo di soluzione attualmente implementata nel middleware MADARA (http://madara.sourceforge.net/) tramite l'opzione di trasporto REGISTRY_CLIENT.
Per noi, abbiamo optato per quello che potreste chiamare un server di registro o un servizio di nomi (se avete familiarità con CORBA) per gli endpoint P2P. Il server di registro deve essere eseguito su un ip pubblico: porta che UDP può raggiungere in un messaggio a senso unico. Per i nostri test, abbiamo affittato un nodo Amazon EC2 e verificato che le impostazioni del firewall consentissero il traffico UDP attraverso una porta UDP a cui ci saremmo associati. Sul lato server (l'IP pubblico: accoppiamento delle porte per il server del registro), ci colleghiamo alla porta e attendiamo la registrazione dei client. Qualsiasi client P2P che vuole parlare con gli altri invia un messaggio di registro al Registro Server
P2P client ----> [register message] ---> Registry Server
Il messaggio di registro può avere contenuti arbitrari. In realtà non hanno contenuti diversi da un'intestazione del messaggio dal nostro normale protocollo di dati. Sul lato server, controlliamo l'host remoto del mittente del messaggio di registro (il client P2P in alto a sinistra) tramite le normali chiamate recv socket. Questo host remoto deve essere l'informazione dell'endpoint attraverso il firewall che protegge il client P2P.
Per capire cosa sta succedendo qui, dobbiamo osservare come i messaggi vengono instradati per il client P2P al nostro server di registro pubblico. Il seguente diagramma ASCII mostra le informazioni remote che un socket potrebbe visualizzare (ad esempio un firewall firewall di esempio) lungo il percorso da un client P2P al nostro server EC2. Questo mostra solo un firewall, ma dovrebbe funzionare con più NAT tra il client P2P e il server di registro, purché i NAT mantengano l'IP pubblico: le porte si aprono quando il traffico passa attraverso l'IP assegnato: porta in quel particolare NAT.
P2P client ----> [message from 192.168.1.10:35000] ---> Firewall ---> [message from 111.111.50.34:5627] --> Registry Server
Ora, se abbiamo cercato di inviare un messaggio a 192.168.1.10:35000 dal nostro server del registro, fallirebbe (o almeno, sarebbe quasi certamente andare al posto sbagliato). Allo stesso modo, puoi vedere che il 4G Firewall sta cambiando anche la porta da 35000 a 5627. Per inviare un messaggio al client P2P, dovrai fare due cose: 1) inviare un messaggio di risposta tramite 111.111.50.34:5627 piuttosto di qualsiasi ip: le informazioni sulla porta inizialmente collegate al lato client P2P e 2) assicuratevi che il client P2P o il server di registro invii di nuovo i dati a vicenda frequentemente - una volta al secondo sembrava soddisfacente per il nostro scopo di legarsi in modo permanente a l'IP pubblico: porta di 111.111.50.34:5627, nel nostro esempio.
Come parte del nostro protocollo, non inviamo semplicemente un pacchetto inutile al client P2P registrato. Inviamo tutti gli IP pubblici rilevanti: le coppie di porte dei client P2P che si trovano nel gruppo/clique/dominio/gruppo di quel cliente. In sostanza, inviamo le informazioni di individuazione client P2P per tutto ciò che il server del registro è a conoscenza di ciò che sembra rilevante per il client P2P.
Ad esempio, supponiamo che due client P2P abbiano inviato messaggi di messaggistica al server di registro tramite 111.111.50.34:5627 e 111.111.37.24:15234 ip: port binding tramite il firewall del provider 4G. Un nuovo client P2P si collega da 111.111.70.105:7000, e noi rispondiamo indietro con gli altri 2 punti finali in un semplice elenco:
[Registry Response for P2P Client #3]
111.111.50.34:5627
111.111.37.24:15234
Ora, sul P2P client # 3 della fine, si prende questa lista e l'uso come potenziali endpoint per la tua applicazione P2P. Questi sono i tuoi pari P2P. Puoi creare pacchetti UDP tramite lo stesso socket con cui ti sei registrato e fintanto che non sono protetti da firewall conservativi (come gli hotspot tethered mobili sul tuo telefono, che dalla mia esperienza sono tradizionalmente progettati per bloccare tutto il traffico UDP in entrata sulla porta effimera collegamenti senza impostazioni di configurazione disponibili per abilitare il port forwarding) e il traffico dovrebbe essere in grado di fluire in entrambe le direzioni.
Come notato in precedenza, per mantenere valide le connessioni UDP P2P, in pratica è sufficiente inviare nuovamente i dati periodicamente a/da questo endpoint per mantenere l'IP pubblico: binding della porta attivo e attivo su ciascun firewall che protegge i client P2P. Ciò può essere fatto reinviando periodicamente le informazioni di registrazione al server pubblico di registro e/o ricevendo pacchetti UDP da altri client P2P a quell'ip pubblica: la porta che il firewall 4G ha assegnato al proprio client P2P.
Sì, lo sono! Guarda la mia risposta! Ho preso due dei riferimenti sulla mia risposta da quella pagina di Wikipedia !!! –
Non importa. La tecnica della Waseda University potrebbe funzionare per alcuni router simmetrici di dimensioni più ridotte (non ne ho visti molti io), ma l'ho implementato personalmente e NON funziona per reti 3/4G. –