UDP Hole Punching

[vtrx]

Alguém que conhece poderia tentar me explicar esta técnica?

[Rodrigo_P_A]

Tem explicado na RFC.

https://tools.ietf.org/html/rfc5128

Vou explicar de forma "simplista", da forma que eu entendi como funciona, se tiver algum erro, fiquem à vontade para me corrigir, para que eu aprenda mais também.

Exemplo:
Máquina 1 quer falar com a máquina 2 diretamente

SERVIDOR -> para iniciar a conexão
MAQUINA 1 -> atras de roteadores etc..
MAQUINA 2 -> atras de roteadores etc...

SERVIDOR ESCUTANDO NA PORTA 1234

MAQUINA 1 -> ENVIA MENSAGEM PARA O SERVIDOR NA PORTA 1234, neste momento o servidor sabe a porta que está sendo usada pela maquina 1, por exemplo, ele pediu para se conectar ao servidor na porta 1234, mas atravessou vários roteadores e a conexão de saída dele é feita na porta através do IP PUBLICO da MAQUINA 1 e PORTA 4123 (apenas um exemplo)

Quando o servidor responde para a MAQUINA 1, ele manda a mensagem para o IP PUBLICO da maquina 1 e porta 4123 , as rotas internas são feitas pelos roteadores, as portas mudam quando passam de um equipamento para outro.

MAQUINA 2 -> Envia mensagem para o servidor porta 1234, da mesma forma que a maquina 1, mas por exemplo, a porta usada pela maquina 2 é IP_PUBLICO porta 51099 (apenas exemplo). Quando o servidor responder para a maquina 2, ele vai enviar a mensagem para IP_PUBLICO da maquina 2, porta 51099

Neste momento o servidor sabe qual IP PUBLICO de cada maquina, e se a MAQUINA 1 enviar um dado UDP para o IP PUBLICO da MAQUINA2:51099 a máquina 2 vai receber os dados. e se a MAQUINA 2 enviar dado para a IP_PUBLICO_MAQUINA1:4123 ela vai receber.

Isso acontece, pois as rotas permanecem nas tabelas internas dos roteadores por algum tempo, isso varia de acordo com o tipo de equipamento, mas geralmente funciona.

À partir disso, você pode criar mecanismos de comunicação direta P2P UDP entre uma máquina e outra, já fiz uns testes, e funciona. A maioria dos aplicativos P2P usam essa técnica, que pelo que eu vi, é a mais simples , e não precisa configurar nada nos roteadores.

[andre_luis]

Pelo que voce explicou, seria uma espécie de tunelamento da conexão, tal como o VPN ?

[Rodrigo_P_A]

Não é tunel, após conhecida as portas, uma máquina fala diretamente com a outra.

O servidor, serve apenas para que controle a lógica e informe para uma máquina e outra as portas e ips a serem usados para se falarem diretamente, já que estou partindo do principio que os Ips das máquinas 1/2 não são fixos, e que não temos acesso aos roteadores.

[vtrx]

Acho que agora entendi,mas minha dúvida é por um motivo.
Tenho alguns aplicativos Delphi/Banco de dados <->Android,mas queria um aplicativo Android<->PC,sem a necessidade de alterar algo no roteador ou usar um servidor.
A única maneira de fazer isso é usando um servidor?
Usando servidor demando mais um custo.
Não existe um método de procura sem um servidor fixo?

[Rodrigo_P_A]

Acho que agora entendi,mas minha dúvida é por um motivo.
Tenho alguns aplicativos Delphi/Banco de dados <->Android,mas queria um aplicativo Android<->PC,sem a necessidade de alterar algo no roteador ou usar um servidor.
A única maneira de fazer isso é usando um servidor?
Usando servidor demando mais um custo.
Não existe um método de procura sem um servidor fixo?

Para fazer atravessando tudo, usando IPs dinâmicos (ou seja, sem conhecer os IPs), sem mexer em roteadores, só com servidor intermediário para "iniciar e gerenciar as 'conexões'" , não é tão simples de ser feito, mas é assim que é feito com sistemas P2P.

UDP Hole Punching é mais simples do que o TCP Hole punching... a técnica usando TCP eu ainda num entendi nem consegui testar. De qualquer forma, tem que ter um servidor no meio quando não se conhece nada da rede nem os ips

[tcpipchip]

é o que faz o remot3.it