rnl

Avertissement

RNL y compris son code cryptographique n'est pas audité jusqu'à présent, RNL est donc uniquement destiné aux jeux en temps réel et aux applications multimédia sans traitement de données critiques, mais pas aux applications sérieuses avec des données critiques !

Description

RNL signifie « Bibliothèque de réseau en temps réel »

RNL est une bibliothèque réseau basée sur UDP pour les applications et les jeux en temps réel, inspirée de ENet, Yojimbo, libgren, etc.

RNL est conçu autour de modèles courants utilisés dans les jeux en temps réel, qui sont liés à la simulation, non aux E/S, et complètement avec état, donc les E/S asynchrones n'ont pas beaucoup de sens. Ainsi, la conception de base de RNL est monothread et non multithread. Mais vous pouvez utiliser plusieurs instances TRNLHost dans plusieurs threads différents (une à très peu d'instances par thread), de sorte que vous puissiez héberger plusieurs matchs de jeu en réseau sur la même machine, à condition que cette machine soit suffisamment puissante et rapide pour en héberger plusieurs. matchs de jeu en réseau en même temps.

Et côté client du jeu, l'ensemble du réseau doit fonctionner, si possible, dans son propre thread (également si possible, épinglé par le cœur du processeur), pour éviter d'éventuelles interférences et autres problèmes similaires. (hors sujet : la même chose s'applique également au fil audio, à moins que l'on n'apprécie les éventuels problèmes de sous-utilisation du tampon audio, etc., lorsqu'il n'a pas obtenu suffisamment de temps CPU aux bons moments. :-) )

Et pour les jeux plus importants avec des masses de clients dans un seul monde de jeu, vous devez utiliser plusieurs instances TRNLHost subdivisées, de sorte que chaque TRNLHost ne doive gérer que quelques clients connectés, dans plusieurs threads et cela à leur tour sur plusieurs serveurs physiques dédiés, qui à leur tour peuvent communiquer entre eux pour imiter l'impression d'un seul très grand monde de jeu. Au moins une seule instance TRNLHost est plutôt conçue pour un faible nombre de clients, comme c'est le cas typique pour les jeux de tir sur l'ego, les jeux de course, etc. Ou en d'autres termes pour les grands mondes de jeu avec des masses de clients : diviser pour mieux régner (par exemple avec des secteurs de monde de jeu qui se chevauchent partiellement aux frontières des secteurs, juste à titre d'exemple d'idée de concept diviser pour régner)

Soutenez-moi

Soutenez-moi chez Patreon

Caractéristiques

• Conception de code principalement entièrement orientée objet
• Prise en charge d'IPv6
• Plateforme multiplateforme
  • Windows (avec FreePascal et Delphi)
  • Linux (avec FreePascal)
  • *BSD (avec FreePascal)
  • Android (avec FreePascal et Delphi)
  • Darwin (MacOS(X) et iOS) (avec FreePascal et Delphi)
• Protocole basé sur UDP
• Séquençage
• Canaux
  • Avec les types de canaux configurables gratuitement suivants :
    • Fiable commandé
    • Fiable et non commandé
    • Commande peu fiable
    • Peu fiable et non ordonné
• Fiabilité
• Fragmentation et réassemblage
• Agrégation
• Adaptabilité
• Portabilité
• Possibilité d'utiliser un modèle peer-to-peer ou même un modèle hybride peer-to-peer et client/serveur à la place d'un modèle client/serveur pur, et bien sûr aussi d'un modèle client/serveur classique
• Générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG)
  • Basé sur arc4random mais avec ChaCha20 à la place de RC4 comme élément de base
  • Plusieurs sources d'entropie (car vous ne devez jamais faire confiance à une seule source d'entropie, car elle peut avoir une porte dérobée)
    • Y compris l'utilisation des instructions rdseed/rdrand sur les processeurs x86 plus récents en tant que source d'entropie quasi matérielle supplémentaire facultative, si ces instructions sont prises en charge par le processeur en cours d'exécution
• Authentification mutuelle
  • Basé sur un protocole de type Station-to-Station (STS), qui suppose que les parties disposent de clés de signature, qui sont utilisées pour signer les messages, offrant ainsi une sécurité de minification contre les attaques de l'homme du milieu, contrairement au protocole de base Diffie- Méthode Hellman sans de telles extensions.
  • Les clés privées/publiques à long terme sont des clés ED25519 et sont utilisées uniquement à des fins de signature
• Secret direct utilisant la courbe elliptique éphémère Diffie-Hellman (courbe 25519)
  • La conséquence de ceci et d'autres faits est que chaque connexion a toujours de nouvelles clés privées et publiques à court terme des deux côtés et donc également de nouvelles clés secrètes partagées à court terme.
  • Les clés privées/publiques à court terme sont des clés X25519 et la clé secrète partagée à court terme est utilisée uniquement à des fins de chiffrement basé sur AEAD.
• Chiffrement authentifié avec chiffrement de paquets de données associées (AEAD)
  • Basé sur ChaCha20 comme chiffre et Poly1305 comme code d'authentification de message cryptographique
• Protection contre la relecture des données des paquets d'application
  • Basé sur divers mécanismes de protection lors de la phase d'établissement de la connexion et sur des numéros de séquence de paquets cryptés
• Mécanisme d'établissement de connexion retardé comme mécanisme supplémentaire de minification de la surface d'attaque
• Jetons de connexion et d'authentification (en option facultative, où vous devez disposer d'un canal de communication hors bande distinct, par exemple un backend principal basé sur HTTPS pour générer et gérer ces éléments) comme mécanisme supplémentaire de minification de la surface d'attaque contre l'amplification DDoS attaques
  • Les jetons de connexion sont transférés en texte clair, de sorte qu'ils soient vérifiés rapidement dès le premier paquet de données provenant d'une tentative de connexion, sans qu'il soit nécessaire de déchiffrer le jeton de connexion avant qu'il ne soit possible de vérifier le jeton, afin de économiser du temps CPU sur ce point. Cette option est principalement destinée à être utilisée contre les attaques par amplification DDoS, ce qui signifie que le serveur ne répondra pas immédiatement si le jeton de connexion ne correspond pas au premier paquet de données issu d'une tentative de connexion, et donc les attaques par amplification DDoS iront simplement dans le rien. Par conséquent, ces jetons ne doivent être valables que pendant une courte période, ce qui s'applique également au côté backend principal de votre infrastructure.
  • Les jetons d'authentification sont transférés cryptés, une fois que l'échange de clé privée/publique, la génération de clé secrète partagée, etc. ont été traités avec succès. Les jetons d'authentification, contrairement au jeton de connexion, ne constituent PAS une contre-mesure contre les attaques de catégorie DDoS, mais plutôt, comme leur nom l'indique, les jetons d'authentification sont uniquement destinés à des fins d'authentification de canal de communication hors bande distinctes, en d'autres termes, à titre supplémentaire. protection contre les connexions non autorisées, où vous pouvez le vérifier plus en détail du côté backend principal de votre infrastructure, avant que le « client » puisse se connecter au serveur réel, où se déroule toute l'action réelle.
• Limiteur de taux de tentatives de connexion
  • Configurable avec deux constantes, burst et période
• Limiteur de débit de bande passante configurable
• Fonctionnalité de réseau virtuel facultative (par exemple pour une solution de bouclage local rapide sans API réseau pour les matchs de jeu solo, qui devrait toujours être basée sur le concept serveur/client)
• Simulateur d'interférence réseau (par exemple pour les cas de test, etc.)
  • Probabilité de perte de paquets simulée configurable (chacune pour les paquets entrants et sortants)
  • Latence simulée configurable (chacune pour les paquets entrants et sortants)
  • Gigue simulée configurable (chacune pour les paquets entrants et sortants)
  • Probabilité de paquets en double simulée configurable (chacune pour les paquets entrants et sortants)
• Mécanisme d'ajustement de la difficulté de réponse à une demande de défi de connexion dynamique
  • Configurable avec une valeur de facteur
  • Basé sur un mécanisme de détermination de style lissage de l'historique, mais uniquement sur les images par seconde, les tentatives de connexion par seconde
• Plus d'algorithmes de compression comme choix
  • Deflate (un LZ77 compatible avec le flux binaire zlib et un hybride Huffman canonique, uniquement Huffman-canonique-statique fixe dans cette implémentation ici du côté du compresseur, mais le côté du décompresseur est complet)
  • LZBRRC (un compresseur de style LZ77 avec un backend de codeur de plage d'entropie)
  • BRRC (un codeur de plage d'entropie d'ordre pur 0)
• CRC32C au lieu de CRC32 (sans C à la fin)
• Et bien d'autres choses encore. . .

Fonctionnalités planifiées (alias Todo) dans un ordre aléatoire de priorités

• FAIRE

Directives générales pour les contributeurs de code

Directives générales pour les contributeurs de code

Licence

Licence zlib

canal IRC

Canal IRC #rnl sur Freenode

Merci

• Merci à Lee Salzman pour ENet comme source d'inspiration pour les idées de mise en œuvre de la conception de l'API de base
• Merci à Glenn Fiedler pour son inspiration pour les idées de mise en œuvre axées sur la sécurité
• Merci à Sergey Ignatchenko ("No Bugs" Hare) pour son inspiration également pour les idées de mise en œuvre axées sur la sécurité