A sinaliza\u00e7\u00e3o est\u00e1 intimamente relacionada \u00e0 nossa implementa\u00e7\u00e3o de soquetes, descrita na pr\u00f3xima se\u00e7\u00e3o.<\/li>\n<\/ul>\n\nLista de servidores dentro do jogo e na p\u00e1gina inicial<\/i><\/p>\nImplementa\u00e7\u00e3o de soquetes<\/h1>\n
\nQueremos criar uma API o mais pr\u00f3ximo poss\u00edvel dos Soquetes UDP Posix, para minimizar o n\u00famero de altera\u00e7\u00f5es necess\u00e1rias.<\/p>\n
Al\u00e9m disso, queremos implementar o m\u00ednimo necess\u00e1rio para a troca simples de dados pela rede.<\/p>\n
Por exemplo, n\u00e3o precisamos de roteamento real: todos os peers est\u00e3o em uma 'LAN virtual' ligada a uma inst\u00e2ncia espec\u00edfica do banco de dados Firebase.<\/p>\n
Portanto, n\u00e3o precisamos de endere\u00e7os IP exclusivos: para a identifica\u00e7\u00e3o \u00fanica dos peers, basta usar valores de chave exclusivos do Firebase (semelhante a nomes de dom\u00ednio), e cada peer localmente atribui endere\u00e7os IP 'falsos' a cada chave que precisa ser convertida. Isso nos livra completamente da necessidade de atribui\u00e7\u00e3o global de endere\u00e7os IP, o que \u00e9 uma tarefa n\u00e3o trivial.<\/p>\n
Aqui est\u00e1 a API m\u00ednima que precisamos implementar:<\/p>\n
\/\/ Create and destroy a socket\nint socket();\nint close(int fd);\n\/\/ Bind a socket to a port, and publish it on Firebase\nint bind(int fd, AddrInfo* addr);\n\/\/ Send a packet. This lazily create a WebRTC connection to the \n\/\/ peer when necessary\nint sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);\n\/\/ Receive the packets destined to this socket\nint recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);\n\/\/ Be notified when new packets arrived\nint recvCallback(Callback cb);\n\/\/ Obtain a local ip address for this peer key\nuint32_t resolve(client::String* key);\n\/\/ Get the peer key for this ip\nString* reverseResolve(uint32_t addr);\n\/\/ Get the local peer key\nString* local_key();\n\/\/ Initialize the library with the given Firebase database and \n\/\/ WebRTc connection options\nvoid init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);<\/code><\/pre>\n\nA API \u00e9 simples e semelhante \u00e0 API Posix Sockets, mas possui algumas diferen\u00e7as importantes: registro de callbacks, atribui\u00e7\u00e3o de IPs locais e conex\u00e3o 'pregui\u00e7osa'<\/strong>.<\/p>\nRegistro de callbacks<\/h2>\n \nMesmo que o programa original utilize E\/S n\u00e3o bloqueante, para execu\u00e7\u00e3o em um navegador, o c\u00f3digo precisa ser refatorado.<\/p>\n
A raz\u00e3o para isso \u00e9 que o loop de eventos no navegador est\u00e1 oculto para o programa (seja JavaScript ou WebAssembly).<\/p>\n
No ambiente nativo, podemos escrever o c\u00f3digo desta forma<\/p>\n
while(running) {\n select(...); \/\/ aguardar eventos de E\/S\n while(true) {\n int r = readfrom(...); \/\/ tentar ler\n if (r < 0 && errno == EWOULDBLOCK) \/\/ n\u00e3o h\u00e1 mais dados dispon\u00edveis\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nSe o loop de eventos est\u00e1 oculto para n\u00f3s, precisamos transform\u00e1-lo em algo como:<\/p>\n
auto cb = []() { \/\/ isso ser\u00e1 chamado quando novos dados estiverem dispon\u00edveis\n while(true) {\n int r = readfrom(...); \/\/ tentar ler\n if (r < 0 && errno == EWOULDBLOCK) \/\/ n\u00e3o h\u00e1 mais dados dispon\u00edveis\n break;\n ...\n }\n ...\n};\nsomeCallback(cb); \/\/ registrar o callback<\/code><\/pre>\n<\/p>\n
Atribui\u00e7\u00e3o de IPs locais<\/h2>\n \nOs identificadores de n\u00f3s em nossa \"rede\" n\u00e3o s\u00e3o endere\u00e7os IP, mas chaves do Firebase (s\u00e3o strings que se parecem com: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nIsso \u00e9 conveniente, pois n\u00e3o precisamos de um mecanismo para atribuir IPs e verificar sua exclusividade (bem como descart\u00e1-los ap\u00f3s a desconex\u00e3o do cliente), mas muitas vezes \u00e9 necess\u00e1rio identificar pares por um valor num\u00e9rico.<\/p>\n
\u00c9 exatamente para isso que s\u00e3o utilizadas as fun\u00e7\u00f5es resolve<\/code> e reverseResolve<\/code>: o aplicativo de alguma forma obt\u00e9m o valor da chave em string (por meio da entrada do usu\u00e1rio ou por meio de um servidor mestre) e pode convert\u00ea-lo em um endere\u00e7o IP para uso interno. O restante da API tamb\u00e9m recebe, por simplicidade, esse valor em vez da string.<\/p>\nIsso \u00e9 semelhante a uma consulta DNS, exceto que \u00e9 realizada localmente no cliente.<\/p>\n
Ou seja, os endere\u00e7os IP n\u00e3o podem ser compartilhados entre diferentes clientes, e se um identificador global for necess\u00e1rio, ele precisar\u00e1 ser gerado de outra maneira.<\/p>\n
Conex\u00e3o pregui\u00e7osa<\/h2>\n \nUDP n\u00e3o requer conex\u00e3o, mas, como vimos, antes de come\u00e7ar a transmitir dados entre dois pares, o WebRTC exige um longo processo de conex\u00e3o.<\/p>\n
Se quisermos manter o mesmo n\u00edvel de abstra\u00e7\u00e3o, (sendto<\/code>\/recvfrom<\/code> com pares arbitr\u00e1rios sem conex\u00e3o pr\u00e9via), devemos realizar uma conex\u00e3o \"pregui\u00e7osa\" (delayed) dentro da API.<\/p>\nIsso \u00e9 o que acontece durante a troca t\u00edpica de dados entre um \"servidor\" e um \"cliente\" ao usar UDP, e o que nossa biblioteca deve executar:<\/p>\n
\nO servidor chama bind()<\/code>, para informar ao sistema operacional que deseja receber pacotes na porta especificada.<\/li>\n<\/ul>\n\nEm vez disso, vamos publicar uma porta aberta no Firebase sob a chave do servidor e escutar os eventos em seu sub\u00e1rvore.<\/p>\n
\nO servidor chama recvfrom()<\/code>, recebendo nesse porta pacotes provenientes de qualquer host.<\/li>\n<\/ul>\n\nNo nosso caso, precisamos verificar a fila de entrada de pacotes enviados para essa porta.<\/p>\n
Cada porta tem sua pr\u00f3pria fila, e adicionamos nos datagramas WebRTC as portas de origem e destino, para saber em qual fila redirecionar quando um novo pacote chegar.<\/p>\n
A chamada \u00e9 n\u00e3o bloqueante, portanto, se n\u00e3o houver pacotes, simplesmente retornamos -1 e definimos errno=EWOULDBLOCK<\/code>.<\/p>\n\nO cliente obt\u00e9m IP e a porta do servidor por meios externos e chama sendto()<\/code>. Tamb\u00e9m ocorre uma chamada interna, bind()<\/code>, portanto, o subsequente recvfrom()<\/code> receber\u00e1 uma resposta sem a execu\u00e7\u00e3o expl\u00edcita de bind.<\/li>\n<\/ul>\n\nNeste caso, o cliente recebe externamente uma chave de string e utiliza a fun\u00e7\u00e3o resolve()<\/code> para obter o endere\u00e7o IP.<\/p>\nNeste est\u00e1gio, come\u00e7amos o 'handshake' do WebRTC, caso os dois pares ainda n\u00e3o estejam conectados entre si. Conex\u00f5es em diferentes portas de um mesmo par utilizam o mesmo DataChannel do WebRTC.<\/p>\n
Al\u00e9m disso, realizamos uma indireta bind()<\/code>, para que o servidor possa restaurar a conex\u00e3o na pr\u00f3xima sendto()<\/code> caso ela tenha sido encerrada por algum motivo.<\/p>\nO servidor \u00e9 notificado da conex\u00e3o do cliente quando o cliente registra sua oferta SDP sob a informa\u00e7\u00e3o da porta do servidor no Firebase, e o servidor responde l\u00e1 mesmo com sua resposta.<\/p>\n
\nNo esquema mostrado abaixo, \u00e9 apresentado um exemplo do fluxo de mensagens para o esquema de sockets e a transmiss\u00e3o da primeira mensagem do cliente para o servidor:<\/p>\n
Esquema completo da etapa de conex\u00e3o entre o cliente e o servidor.<\/i><\/p>\nConclus\u00e3o<\/h1>\n
\nSe voc\u00ea chegou at\u00e9 aqui, deve estar interessado em ver a teoria em a\u00e7\u00e3o. O jogo pode ser jogado em teeworlds.leaningtech.com<\/a><\/noindex>, experimente!<\/p>\n