A morte do encaminhamento de portas: Como o WebRTC está salvando o Retro Netplay

Durante muito tempo, a “era dourada” dos jogos retro ficou presa atrás de uma barreira de menus com texto azul, endereços IP confusos e o temido Reencaminhamento de portas. Se cresceste nos anos 2000 a tentar jogar um clássico jogo de luta de arcada ou um jogo de plataformas de 8 bits com um amigo do outro lado do país, provavelmente passaste mais tempo nas definições do teu router do que no próprio jogo. Tinhas de aceder ao 192.168.1.1, encontrar as definições de NAT e rezar para que abrir a porta 27015 não deixasse o computador da tua família vulnerável a todos os script kiddies do bairro.

Mas em Rec0m88, já ultrapassámos essa fase. Ao tirar partido de WebRTC (Comunicação em tempo real na Web), eliminámos efetivamente a necessidade de configuração manual da rede. Aqui fica uma análise técnica aprofundada sobre o motivo pelo qual o WebRTC é a espinha dorsal revolucionária do netplay moderno e como resolve a “crise de conectividade” que assolou a emulação retro durante décadas.

O problema: a grande barreira do NAT

Para compreender por que razão o WebRTC representa uma revolução, é preciso perceber por que razão o «netplay» à moda antiga era tão complicado. A maioria dos utilizadores domésticos da Internet não dispõe de um endereço IP público direto para o seu computador. Em vez disso, encontram-se atrás de um NAT (Tradução de Endereços de Rede) gateway — o seu router.

Quando tentavas organizar uma partida num emulador antigo, o computador do teu amigo enviava um pacote para o teu router, e o teu router respondia:, “Não sei a que aparelho desta casa se destina este pacote”,” e desativá-la imediatamente. É por isso que tiveste de “redirecionar” a porta. Estavas a indicar manualmente ao router: “Tudo o que chega ao Port X vai para o meu computador de jogos.”

Foi um processo repleto de atritos que impediu que 90% de jogadores ocasionais pudessem alguma vez experimentar a alegria dos jogos retro online para dois jogadores.

A solução: WebRTC e a estrutura “ICE”

O WebRTC não pede ao utilizador para resolver os problemas de rede; é ele que resolve esses problemas pelo utilizador. Utiliza uma estrutura chamada ICE (Estabelecimento de Conectividade Interativa) para encontrar o caminho de menor resistência entre dois jogadores. Este processo ocorre em milésimos de segundo, nos bastidores:

1. STUN (Utilitários de Traversal de Sessão para NAT): O teu navegador envia um pedido a um servidor STUN apenas para perguntar: “Qual é o meu endereço IP público e a minha porta?” Assim que souber qual é a sua “imagem pública”, partilha essa informação com o outro jogador através do nosso servidor de sinalização.
2. Perfuração de portas UDP: Como ambos os jogadores estão a enviar “pings” um ao outro simultaneamente, muitos routers modernos interpretam isto como uma comunicação “solicitada” e abrem automaticamente uma abertura temporária na firewall. Não é necessário efetuar qualquer reencaminhamento manual de portas.
3. TURN (Traversal Using Relays around NAT): Em cerca de 10 a 15% dos casos — normalmente em redes empresariais ou universitárias restritas —, nem mesmo o «hole punching» funciona. Nestes cenários, o WebRTC recorre a um servidor TURN, que atua como um retransmissor de alta velocidade, garantindo que a sessão de jogo continue a funcionar onde os emuladores antigos simplesmente não conseguiam estabelecer ligação.

Porque não usar simplesmente WebSockets?

Muitos programadores web tentam criar jogos utilizando WebSockets, mas para jogos retro de alta velocidade (como Street Fighter ou Contra), os WebSockets são um desastre. Os WebSockets funcionam em TCP (Protocolo de Controlo de Transmissão).

O TCP é “fiável”, o que significa que, se um único pacote de dados se perder, todo o fluxo pára e aguarda que esse pacote seja reenviado. Num jogo, isto provoca “falhas” ou “gaguejos”. Se a tua personagem saltar, mas o pacote se perder, o jogo congela durante 200 ms enquanto aguarda a chegada do comando de salto.

O WebRTC utiliza o UDP (Protocolo de Datagramas do Utilizador). Num ambiente de jogo online baseado em UDP, se um pacote se perder, simplesmente passamos para o seguinte. Isto permite uma experiência muito mais fluida, um “estado de fluxo”, em que a latência parece consistente, em vez de irregular.

Segurança sem stress

Uma das vantagens mais subestimadas da abordagem WebRTC no Rec0m88 é privacidade. Nos velhos tempos em que se partilhavam endereços IP no Discord ou no IRC, estava-se a revelar, literalmente, o endereço digital de casa a estranhos.

O WebRTC num ambiente de navegador está fortemente isolado numa «sandbox». Proporciona DTLS (Segurança da Camada de Transporte de Datagramas) e SRTP (Protocolo Seguro de Transporte em Tempo Real) encriptação por predefinição. Os seus dados são encriptados de ponta a ponta e, como o emulador funciona no navegador, nunca tem acesso de “administrador” ao seu computador local. Obtém o desempenho de uma aplicação nativa em C++ com a segurança de um navegador web moderno.

O futuro do Netplay é o «Zero-Config»

Na Rec0m88, acreditamos que a tecnologia deve passar despercebida para que o jogo assuma o protagonismo. Ao utilizar canais de dados WebRTC, reduzimos a barreira de acesso ao jogo online retro de “nível de técnico de informática” para “nível de um clique”.”

Quer estejas a organizar uma sala para um jogo de ação com 4 jogadores ou para um jogo de luta 1 contra 1, a complexa interação entre a traversal NAT, a descoberta STUN e a sinalização UDP ocorre num piscar de olhos. A era do ’anfitrião inacessível“ chegou ao fim.

Está pronto para testar a latência por si próprio? Experimenta os nossos jogos de arcada e inicie uma sessão de Netplay para ver o WebRTC em ação.