Advertencia
RNL, incluido su código criptográfico, no está auditado hasta el momento, por lo que RNL solo está destinado a juegos en tiempo real y aplicaciones multimedia sin procesamiento de datos críticos, ¡pero no para aplicaciones serias con datos críticos!
Descripción
RNL significa "Biblioteca de red en tiempo real"
RNL es una biblioteca de red basada en UDP para aplicaciones y juegos en tiempo real, inspirada en ENet, yojimbo, libgren, etc.
RNL está diseñado en torno a patrones comunes utilizados en juegos en tiempo real, que están vinculados a la simulación, no a la E/S, y son completamente con estado, por lo que la E/S asíncrona no tiene mucho sentido. Por lo tanto, el diseño del núcleo de RNL es de un solo subproceso, no de múltiples subprocesos. Pero puede usar múltiples instancias de TRNLHost dentro de múltiples subprocesos diferentes (de una a muy pocas instancias por subproceso), de modo que pueda albergar múltiples partidas de juegos en red en la misma máquina, siempre que esta máquina sea lo suficientemente potente y rápida para albergar múltiples partidos de juegos en red al mismo tiempo.
Y en el lado del cliente del juego, toda la red debe ejecutarse, si es posible, en un hilo propio (también si es posible, fijado al núcleo de la CPU), para posibles pocas interferencias y otros problemas similares. (fuera de tema: lo mismo también se aplica al hilo de audio, a menos que a uno le gusten posibles problemas de insuficiencia de datos del búfer de audio, etc., cuando no obtuvo suficiente tiempo de CPU en los momentos correctos. :-))
Y para juegos más grandes con una gran cantidad de clientes en un solo mundo de juego, debes usar varias instancias de TRNLHost subdivididas, de modo que cada TRNLHost deba manejar solo unos pocos clientes conectados, en múltiples subprocesos y, a su vez, en múltiples servidores físicos dedicados, que también a su vez pueden comunicarse entre sí para imitar la impresión de un único mundo de juego muy grande. Al menos una única instancia de TRNLHost está más bien diseñada para un número de clientes bajo, como es el caso típico de los egoshooters, los juegos de carreras, etc. O en otras palabras, para mundos de juego grandes con masas de clientes: divide y vencerás (por ejemplo, con sectores de mundos de juego parcialmente superpuestos en los límites de los sectores, solo como ejemplo de una idea conceptual de divide y vencerás)
apoyame
Apóyame en Patreon
Características
- Diseño de código mayoritariamente totalmente orientado a objetos.
- soporte IPv6
- Plataforma cruzada
- Windows (con FreePascal y Delphi)
- Linux (con FreePascal)
- *BSD (con FreePascal)
- Android (con FreePascal y Delphi)
- Darwin (MacOS(X) e iOS) (con FreePascal y Delphi)
- Protocolo basado en UDP
- Secuenciación
- Canales
- Con los siguientes tipos de canales configurables libremente:
- Pedido confiable
- confiable desordenado
- Ordenado poco confiable
- desordenado poco confiable
- Fiabilidad
- Fragmentación y reensamblaje
- Agregación
- Adaptabilidad
- Portabilidad
- Posibilidad de utilizar un modelo peer-to-peer o incluso un modelo híbrido peer-to-peer y cliente/servidor en lugar de un modelo cliente/servidor puro y, por supuesto, también un modelo cliente/servidor clásico.
- Generador de números pseudoaleatorios criptográficamente seguro (CSPRNG)
- Basado en arc4random pero con ChaCha20 en lugar de RC4 como bloque de construcción básico
- Múltiples fuentes de entropía (porque nunca debes confiar en una sola fuente de entropía, ya que puede tener una puerta trasera)
- Incluyendo el uso de las instrucciones rdseed/rdrand en procesadores x86 más nuevos como fuente de entropía adicional opcional basada en cuasi hardware, si estas instrucciones son compatibles con el procesador en ejecución actual.
- Autenticación mutua
- Basado en un protocolo tipo estación a estación (STS), que supone que las partes tienen claves de firma, que se utilizan para firmar mensajes, proporcionando así seguridad de minificación contra ataques de intermediario, a diferencia del Diffie- Método Hellman sin tales extensiones.
- Las claves públicas/privadas a largo plazo son claves ED25519 y se utilizan únicamente con fines de firma.
- Secreto directo mediante curva elíptica efímera de Diffie-Hellman (curva 25519)
- La consecuencia de esto, junto con otros hechos, es que cada conexión siempre tiene nuevas claves de corto plazo privadas y públicas diferentes en ambos lados y, por lo tanto, también nuevas claves secretas de corto plazo compartidas.
- Las claves públicas/privadas a corto plazo son claves X25519 y la clave secreta compartida a corto plazo se utiliza únicamente para fines de cifrado basado en AEAD.
- Cifrado de paquetes de cifrado autenticado con datos asociados (AEAD)
- Basado en ChaCha20 como cifrado y Poly1305 como código de autenticación de mensajes criptográficos
- Protección de reproducción de datos de paquetes de aplicaciones
- Basado en varios mecanismos de protección en la fase de establecimiento de la conexión y números de secuencia de paquetes cifrados
- Mecanismo de establecimiento de conexión retrasado como mecanismo adicional de minificación de la superficie de ataque
- Tokens de conexión y autenticación (como opción opcional, donde debería tener un canal de comunicación fuera de banda separado, por ejemplo, un backend maestro basado en HTTPS para generar y manejar estas cosas) como mecanismo adicional de minificación de la superficie de ataque contra la amplificación de DDoS. ataques
- Los tokens de conexión se transfieren en texto claro, de modo que se verifican de manera rápida en el primer paquete de datos de un intento de conexión, sin necesidad de descifrar primero el token de conexión antes de que sea posible verificarlo, por lo que para ahorre tiempo de CPU en este punto. Esta opción se utiliza principalmente contra ataques de amplificación DDoS, lo que significa que el servidor no responderá de inmediato si el token de conexión no coincide en el primer paquete de datos de un intento de conexión y, por lo tanto, los ataques de amplificación DDoS simplemente irían al nada. En consecuencia, estos tokens solo deberían ser válidos por un corto período de tiempo, lo que también se aplica al lado backend maestro de su infraestructura.
- Los tokens de autenticación se transfieren encriptados, después de que se haya procesado con éxito el intercambio de claves pública/privada, la generación de claves secretas compartidas, etc. Los tokens de autenticación, a diferencia del token de conexión, NO son una contramedida contra los ataques de categoría DDoS, sino que, como sugiere el nombre, los tokens de autenticación solo sirven para fines de autenticación de canales de comunicación fuera de banda separados, en otras palabras, como información adicional. protección contra conexiones no autorizadas, donde puede comprobarlo con más detalle en el backend maestro de su infraestructura, antes de que el "cliente" pueda conectarse al servidor real, donde ocurre toda la acción real.
- Limitador de tasa de intentos de conexión
- Configurable con dos constantes, ráfaga y período.
- Limitador de velocidad de ancho de banda configurable
- Función de red virtual opcional (por ejemplo, para una solución rápida de bucle invertido local sin API de red para partidas de un solo jugador, que debería seguir basándose en el concepto de servidor/cliente)
- Simulador de interferencias de red (por ejemplo, para casos de prueba, etc.)
- Probabilidad de pérdida de paquetes simulada configurable (tanto para paquetes entrantes como salientes)
- Latencia simulada configurable (cada una para paquetes entrantes y salientes)
- Jitter simulado configurable (cada uno para paquetes entrantes y salientes)
- Probabilidad configurable de paquetes duplicados simulados (cada uno para paquetes entrantes y salientes)
- Mecanismo de ajuste de dificultad de respuesta de solicitud de desafío de conexión dinámica
- Configurable con un valor de factor
- Basado en un mecanismo de determinación de estilo de suavizado histórico de fotogramas por segundo, pero en su lugar solo fotogramas por segundo, intentos de conexión por segundo.
- Más algoritmos de compresión como opciones
- Deflate (un LZ77 compatible con zlib bit-stream y un híbrido canónico de Huffman, solo fijo-estático-canónico-huffman en esta implementación aquí en el lado del compresor, pero el lado del descompresor tiene todas las funciones)
- LZBRRC (un compresor estilo LZ77 junto con un codificador de rango de entropía)
- BRRC (un codificador de rango de entropía de orden puro 0)
- CRC32C en lugar de CRC32 (sin C al final)
- Y muchas cosas más. . .
Funciones planificadas (también conocidas como Todo) en orden aleatorio de prioridades
Directrices generales para contribuyentes de código
Directrices generales para contribuyentes de código
Licencia
Licencia zlib
canal IRC
Canal IRC #rnl en Freenode
Gracias
- Gracias a Lee Salzman por ENet como inspiración para las ideas de implementación del diseño de API base.
- Gracias a Glenn Fiedler por inspirarnos en ideas de implementación orientadas a la seguridad.
- Gracias a Sergey Ignatchenko ("No Bugs" Hare) por la inspiración y también por las ideas de implementación orientadas a la seguridad.
