La se\u00f1alizaci\u00f3n est\u00e1 estrechamente relacionada con nuestra implementaci\u00f3n de sockets, que se describe en la siguiente secci\u00f3n.<\/li>\n<\/ul>\n\nLista de servidores dentro del juego y en la p\u00e1gina de inicio<\/i><\/p>\nImplementaci\u00f3n de sockets<\/h1>\n
\nQueremos crear una API que se asemeje lo m\u00e1s posible a los Sockets UDP de Posix, para minimizar el n\u00famero de cambios necesarios.<\/p>\n
Tambi\u00e9n queremos implementar el m\u00ednimo necesario requerido para el intercambio de datos m\u00e1s b\u00e1sico por la red.<\/p>\n
Por ejemplo, no necesitamos un enrutamiento real: todos los pares est\u00e1n en una \"LAN virtual\" conectada a una instancia espec\u00edfica de la base de datos de Firebase.<\/p>\n
Por lo tanto, no necesitamos direcciones IP \u00fanicas: para la identificaci\u00f3n \u00fanica de los pares, basta con usar valores \u00fanicos de las claves de Firebase (similar a los nombres de dominio), y cada par asigna localmente direcciones IP \"falsas\" a cada clave que necesita ser traducida. Esto nos libera completamente de la necesidad de asignaciones globales de direcciones IP, que es una tarea no trivial.<\/p>\n
Esta es la API m\u00ednima que necesitamos 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\nLa API es simple y similar a la de los Sockets Posix, pero tiene algunas diferencias importantes: registro de callbacks, asignaci\u00f3n de IP locales y conexi\u00f3n \"perezosa\"<\/strong>.<\/p>\nRegistro de callbacks<\/h2>\n \nIncluso si el programa original utiliza entrada-salida no bloqueante, para ejecutarse en un navegador web, el c\u00f3digo necesita ser reestructurado.<\/p>\n
La raz\u00f3n de esto es que el ciclo de eventos en el navegador est\u00e1 oculto para el programa (ya sea JavaScript o WebAssembly).<\/p>\n
En un entorno nativo, podemos escribir el c\u00f3digo de esta manera<\/p>\n
while(running) {\n select(...); \/\/ espera eventos de I\/O\n while(true) {\n int r = readfrom(...); \/\/ intenta leer\n if (r < 0 && errno == EWOULDBLOCK) \/\/ no hay m\u00e1s datos disponibles\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nSi el ciclo de eventos est\u00e1 oculto para nosotros, entonces necesitamos convertirlo en algo as\u00ed:<\/p>\n
auto cb = []() { \/\/ esto se llamar\u00e1 cuando haya nuevos datos disponibles\n while(true) {\n int r = readfrom(...); \/\/ intenta leer\n if (r < 0 && errno == EWOULDBLOCK) \/\/ no hay m\u00e1s datos disponibles\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registrar el callback<\/code><\/pre>\n<\/p>\n
Asignaci\u00f3n de IP locales<\/h2>\n \nLos identificadores de los nodos en nuestra \u00abred\u00bb no son direcciones IP, sino claves de Firebase (son cadenas que se ven as\u00ed: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nEsto es conveniente, ya que no necesitamos un mecanismo para asignar IP y verificar su unicidad (as\u00ed como su eliminaci\u00f3n tras desconectar al cliente), pero a menudo es necesario identificar pares por un valor num\u00e9rico.<\/p>\n
Para esto se utilizan las funciones resolve<\/code> y reverseResolve<\/code>: la aplicaci\u00f3n de alguna manera obtiene el valor de la clave como una cadena (ya sea mediante la entrada del usuario o a trav\u00e9s de un servidor maestro), y puede convertirlo en una direcci\u00f3n IP para uso interno. El resto de la API tambi\u00e9n, por simplicidad, recibe este valor en lugar de una cadena.<\/p>\nEsto es similar a una b\u00fasqueda DNS, solo que se realiza localmente en el cliente.<\/p>\n
Es decir, las direcciones IP no pueden ser compartidas entre diferentes clientes, y si se necesita un identificador global, tendr\u00e1 que generarse de otra manera.<\/p>\n
Conexi\u00f3n perezosa<\/h2>\n \nUDP no requiere conexi\u00f3n, pero, como hemos visto, antes de comenzar a transferir datos entre dos pares, WebRTC requiere un proceso de conexi\u00f3n prolongado.<\/p>\n
Si queremos proporcionar el mismo nivel de abstracci\u00f3n, (sendto<\/code>\/recvfrom<\/code> con pares arbitrarios sin conexi\u00f3n previa), debemos realizar una conexi\u00f3n \u00abperezosa\u00bb (pospuesta) dentro de la API.<\/p>\nEsto es lo que ocurre durante el intercambio de datos entre el \u00abservidor\u00bb y el \u00abcliente\u00bb en el caso de usar UDP, y lo que debe hacer nuestra biblioteca:<\/p>\n
\nEl servidor llama bind()<\/code>, para informar al sistema operativo que desea recibir paquetes en el puerto especificado.<\/li>\n<\/ul>\n\nEn su lugar, publicamos un puerto abierto en Firebase bajo la clave del servidor y escuchamos eventos en su sub\u00e1rbol.<\/p>\n
\nEl servidor llama recvfrom()<\/code>, recibiendo en este puerto paquetes que llegan desde cualquier host.<\/li>\n<\/ul>\n\nEn nuestro caso, necesitamos verificar la cola de entrada de paquetes enviados a este puerto.<\/p>\n
Cada puerto tiene su propia cola, y a\u00f1adimos al principio de los datagramas WebRTC los puertos de origen y destino, para saber a qu\u00e9 cola redirigir cuando llega un nuevo paquete.<\/p>\n
La llamada es no bloqueante, por lo que si no hay paquetes, simplemente devolvemos -1 y establecemos errno=EWOULDBLOCK<\/code>.<\/p>\n\nEl cliente obtiene de alguna manera la IP y el puerto del servidor, y llama a sendto()<\/code>. Tambi\u00e9n se realiza una llamada interna, bind()<\/code>, por lo que el siguiente recvfrom()<\/code> recibir\u00e1 una respuesta sin la ejecuci\u00f3n expl\u00edcita de bind.<\/li>\n<\/ul>\n\nEn nuestro caso, el cliente obtiene externamente una clave de cadena y utiliza la funci\u00f3n resolve()<\/code> para obtener la direcci\u00f3n IP.<\/p>\nEn esta etapa, comenzamos el \u00abapret\u00f3n de manos\u00bb de WebRTC, si los dos pares a\u00fan no est\u00e1n conectados entre s\u00ed. Las conexiones a diferentes puertos de un mismo par utilizan el mismo DataChannel de WebRTC.<\/p>\n
Tambi\u00e9n realizamos una conexi\u00f3n indirecta bind()<\/code>, para que el servidor pueda restablecer la conexi\u00f3n en el siguiente sendto()<\/code> en caso de que se cierre por alguna raz\u00f3n.<\/p>\nEl servidor es notificado de la conexi\u00f3n del cliente cuando este guarda su oferta SDP bajo la informaci\u00f3n del puerto del servidor en Firebase, y el servidor responde all\u00ed mismo con su respuesta.<\/p>\n
\nEn el diagrama mostrado a continuaci\u00f3n se muestra un ejemplo del movimiento de mensajes para el esquema de sockets y la transmisi\u00f3n del primer mensaje del cliente al servidor:<\/p>\n
Diagrama completo de la etapa de conexi\u00f3n entre el cliente y el servidor<\/i><\/p>\nConclusi\u00f3n<\/h1>\n
\nSi has llegado hasta aqu\u00ed, seguramente te interesa ver la teor\u00eda en acci\u00f3n. Puedes jugar en teeworlds.leaningtech.com<\/a><\/noindex>, \u00a1pru\u00e9balo!<\/p>\n