Jogar com amigos no navegador: como os aparelhos se encontram

Você manda um link no grupo da família. Alguém toca nele, o navegador abre e, alguns segundos depois, essa pessoa está sentada na mesa de UNO com você. Ninguém instalou nada. Parece simples, mas por trás desse toque existe uma pequena negociação entre aparelhos que nunca se viram. Vale abrir a caixa.

O problema: celulares não têm endereço fixo

Na internet, cada conversa precisa de um endereço de origem e um de destino. O seu celular, porém, quase nunca tem um endereço próprio visível para o mundo. Em casa, o roteador recebe um endereço público e distribui endereços privados para todos os aparelhos da rede. Quando o celular manda algo para fora, o roteador troca o endereço privado pelo público e anota uma "porta" para saber a quem devolver a resposta. Esse truque se chama NAT (tradução de endereços de rede).

O NAT funciona muito bem para quem pede: você abre um site, o site responde, o roteador sabe para quem entregar. O difícil é o contrário. Se um amigo tentar mandar dados direto para o seu celular, sem você ter pedido nada, o roteador não sabe a quem entregar e descarta. Nas redes móveis a situação costuma ser ainda mais apertada, porque a operadora também pode colocar muitos clientes atrás de um mesmo endereço público.

Ou seja: dois aparelhos que querem conversar direto precisam primeiro descobrir como chegar um ao outro.

WebRTC: a conexão direta que vem no navegador

A resposta dos navegadores para isso se chama WebRTC (comunicação em tempo real na web). Além de áudio e vídeo, ela oferece os canais de dados: um caminho para mandar mensagens quaisquer de um aparelho a outro, como "joguei o 7 azul".

Dois detalhes importam para quem joga:

• É cifrado por padrão. Tudo o que passa por um canal de dados do WebRTC é protegido pelo DTLS, uma versão da criptografia da web feita para pacotes avulsos.
• Dá para escolher entre ordem e pressa. Um canal pode exigir que as mensagens cheguem na ordem em que saíram, reenviando o que se perdeu, ou pode aceitar perder um pacote velho em troca de rapidez. Para um jogo de cartas, a primeira opção é a certa: nenhuma jogada pode sumir no caminho.

O servidor de sinalização: o apresentador

Antes de conversar direto, os dois aparelhos precisam trocar um "cartão de visita". Esse cartão é um texto no formato SDP que descreve a conexão: que tipo de canal será aberto, quais chaves de criptografia usar e por quais endereços cada lado pode ser alcançado. Um lado cria uma oferta, o outro responde com uma resposta.

O curioso é que o WebRTC não diz como esses cartões devem viajar. A documentação oficial do projeto WebRTC explica que essa troca, chamada de sinalização, fica fora da especificação. Cada aplicação escolhe seu jeito: um servidor qualquer, uma mensagem, até um bilhete, em teoria. O servidor de sinalização é só um apresentador. Ele não precisa entender o conteúdo dos cartões, só entregá-los ao destinatário certo.

STUN e TURN: o espelho e o carteiro

Para preencher o cartão com endereços úteis, o aparelho precisa saber como ele aparece visto de fora. Para isso existe o STUN. O aparelho manda uma pergunta a um servidor STUN público, e o servidor responde algo como "daqui eu vejo você neste endereço e nesta porta". É um espelho: o aparelho descobre o próprio endereço público.

Às vezes isso não basta. Alguns roteadores e redes de operadora só aceitam respostas de quem o aparelho já contatou antes, e cada destino ganha uma porta diferente. O endereço que o espelho mostrou não serve para o amigo. Nesse caso entra o TURN: um servidor de retransmissão que recebe os pacotes de um lado e repassa ao outro. Ele é o carteiro que faz a entrega quando não há caminho direto.

O carteiro tem custo. Todo o tráfego passa por ele, o que exige banda de quem mantém o servidor e acrescenta um desvio no trajeto. Por isso a especificação do TURN, a RFC 8656, recomenda usá-lo só quando não se encontra um caminho direto. Mesmo pelo retransmissor, os dados seguem cifrados entre os dois aparelhos. A página da MDN sobre os protocolos do WebRTC resume bem o papel de cada peça.

ICE: testar todos os caminhos

Quem organiza essa busca é o ICE, descrito na RFC 8445. Cada aparelho junta uma lista de "candidatos", que são caminhos possíveis até ele:

1. Local: o endereço dentro da própria rede. Funciona quando os dois estão no mesmo Wi-Fi.
2. Reflexivo: o endereço público que o espelho STUN revelou.
3. Retransmitido: um endereço emprestado num servidor TURN.

Os dois lados trocam essas listas pela sinalização e começam a testar pares de caminhos, mandando pequenas mensagens de verificação. O que funcionar com mais prioridade é escolhido. A RFC dá a menor prioridade ao caminho retransmitido: ele fica como último recurso.

Por que às vezes demora para conectar

Agora fica mais fácil entender aqueles segundos de "Conectando…". Antes da primeira carta aparecer, acontece uma pequena maratona:

• cada aparelho consulta os servidores de espelho e, se for o caso, pede uma credencial de retransmissão;
• os cartões precisam ir e voltar pelo servidor de sinalização;
• o ICE testa os caminhos, um par de cada vez, e alguns testes só falham depois de esperar uma resposta que não vem;
• se nenhum caminho direto funciona, a conexão cai para o retransmissor, o que soma mais uma etapa.

Redes muito restritas, como as de algumas empresas e escolas, podem bloquear até isso. E há o fator humano: se quem criou a mesa saiu para responder uma mensagem, a página dele fica em segundo plano e só responde ao amigo quando ele voltar ao jogo.

E a latência?

Latência é o tempo que uma mensagem leva de um aparelho a outro. Ela depende da distância, da qualidade da rede e do caminho escolhido. Um caminho direto costuma ser mais curto que um desvio pelo retransmissor. Para um jogo de corrida, cada fração de segundo aparece na tela. Para um jogo de cartas por turnos, a tolerância é bem maior: o que importa é que a jogada chegue inteira e na ordem certa.

Nos bastidores do Jogali: quem é a mesa

Nas mesas com amigos do UNO e do Dominó, a ligação é feita em estrela. Quem abre a sala é o centro, e cada amigo se conecta direto a ele pelo WebRTC. O site do Jogali faz só a apresentação: guarda a oferta de quem chega, entrega ao anfitrião, devolve a resposta e sai do caminho. Em vez de mandar cada endereço assim que é descoberto, o jogo espera alguns instantes para juntar os candidatos e manda o cartão completo de uma vez, o que simplifica a troca.

Primeiro o jogo tenta a ligação direta, com servidores de espelho públicos. Quando a rede não deixa, como acontece com frequência entre dois celulares no 4G, a conexão passa por um retransmissor. O site só entrega a credencial do retransmissor a quem está numa sala de verdade, e ela expira depois de um tempo.

O aparelho de quem abriu a sala é a própria mesa. É ele que embaralha, distribui, confere se cada jogada vale pelas regras e manda a cada pessoa só o que ela pode ver: a própria mão e quantas cartas os outros têm. Os amigos mandam apenas o que querem fazer. Assim ninguém recebe as cartas dos outros no aparelho, nem consegue inventar uma jogada que as regras não permitem.

E se alguém sair? Se um amigo cai no meio da rodada, o computador segura as cartas dele para a partida não parar, e ele volta para o mesmo lugar quando reconecta. Se quem caiu foi o anfitrião e ele só recarregou a página, a partida volta do jeito que estava, porque fica salva no aparelho dele. Se ele some de vez, o site percebe que a mesa ficou sem sinal e a próxima pessoa da lista abre a mesa no lugar dele, com o mesmo código. A partida que estava no aparelho que saiu não vai junto, então a nova mesa começa outra. Quando o anfitrião original volta, a mesa é devolvida a ele e os outros reconectam sozinhos.

Experimente

O UNO do Jogali aceita até 20 pessoas na mesma mesa, com convite pelo WhatsApp e lugares vazios que podem ser completados pelo computador. O Dominó usa a mesma base de conexão, com até 8 pessoas na mesa. Da próxima vez que aparecer "Conectando…", você já sabe: os aparelhos estão testando caminhos para se encontrar.