rnl

Warnung

RNL einschließlich seines Kryptographiecodes ist bisher nicht geprüft, daher ist RNL nur für Echtzeitspiele und Multimediaanwendungen ohne Verarbeitung kritischer Daten gedacht, nicht jedoch für ernsthafte Anwendungen mit kritischen Daten!

Beschreibung

RNL steht für „Realtime Network Library“

RNL ist eine UDP-basierte Netzwerkbibliothek für Echtzeitanwendungen und -spiele, inspiriert von ENet, Yojimbo, Libgren usw.

RNL basiert auf gängigen Mustern, die in Echtzeitspielen verwendet werden. Sie sind an die Simulation gebunden, nicht an E/A-gebunden und vollständig zustandsbehaftet, sodass asynchrone E/A wenig Sinn macht. Daher ist das RNL-Kerndesign Single-Threaded und nicht Multi-Threaded. Sie können jedoch mehrere TRNLHost-Instanzen in mehreren verschiedenen Threads verwenden (eine bis sehr wenige Instanzen pro Thread), sodass Sie mehrere Netzwerkspielspiele auf demselben Computer hosten können, solange dieser eine Computer stark und schnell genug ist, um mehrere zu hosten Netzwerkspiel-Matches gleichzeitig.

Und auf der Seite des Spielclients sollte das gesamte Netzwerkmaterial möglichst in einem eigenen (auch wenn möglich CPU-Kern-festgelegten) Thread laufen, um möglichst wenige Störungen und ähnliche Probleme zu vermeiden. (Offtopic: Das Gleiche gilt auch für den Audio-Thread, es sei denn, man möchte mögliche Probleme mit dem Unterlauf des Audiopuffers usw. haben, wenn zum richtigen Zeitpunkt nicht genügend CPU-Zeit verfügbar war. :-) )

Und für größere Spiele mit Massen an Clients in einer einzigen Spielwelt sollten Sie mehrere unterteilte TRNLHost-Instanzen verwenden, sodass jeder TRNLHost nur wenige verbundene Clients verwalten muss, und zwar in mehreren Threads und das wiederum auf mehreren physischen dedizierten Servern, die auch wiederum können miteinander kommunizieren, um den Eindruck einer einzelnen, sehr großen Spielwelt nachzuahmen. Zumindest eine einzelne TRNLHost-Instanz ist eher für typische geringe Clientzahlen ausgelegt, wie sie bei Egoshootern, Rennspielen usw. typisch sind. Oder mit anderen Worten für große Spielwelten mit einer Vielzahl von Clients: Teile und herrsche (z. B. mit teilweise sektorenüberlappenden Spielweltsektoren, nur als Beispiel für eine Teile-und-Herrsche-Konzeptidee)

Unterstützen Sie mich

Unterstütze mich auf Patreon

Merkmale

• Größtenteils vollständig objektorientiertes Codedesign
• IPv6-Unterstützung
• Plattformübergreifend
  • Windows (mit FreePascal und Delphi)
  • Linux (mit FreePascal)
  • *BSD (mit FreePascal)
  • Android (mit FreePascal und Delphi)
  • Darwin (MacOS(X) und iOS) (mit FreePascal und Delphi)
• UDP-basiertes Protokoll
• Sequenzierung
• Kanäle
  • Mit folgenden möglichen frei konfigurierbaren Kanaltypen:
    • Zuverlässig bestellt
    • Zuverlässig ungeordnet
    • Unzuverlässig bestellt
    • Unzuverlässig ungeordnet
• Zuverlässigkeit
• Fragmentierung und Neuzusammensetzung
• Aggregation
• Anpassungsfähigkeit
• Portabilität
• Möglichkeit der Verwendung eines Peer-to-Peer-Modells oder sogar eines gemischten Peer-to-Peer- und Client/Server-Hybridmodells anstelle nur eines reinen Client/Server-Modells und natürlich auch eines klassischen Client/Server-Modells
• Kryptografisch sicherer Pseudozufallszahlengenerator (CSPRNG)
  • Basierend auf arc4random, aber mit ChaCha20 statt RC4 als Grundbaustein
  • Mehrere Entropiequellen (da Sie niemals einer einzelnen Entropiequelle vertrauen sollten, da diese möglicherweise eine Hintertür hat)
    • Einschließlich der Verwendung der rdseed/rdrand-Anweisungen auf neueren x86-Prozessoren als optionale zusätzliche quasi-hardwarebasierte Entropiequelle, wenn diese Anweisungen vom aktuell laufenden Prozessor unterstützt werden
• Gegenseitige Authentifizierung
  • Basierend auf einem Station-to-Station (STS)-ähnlichen Protokoll, das davon ausgeht, dass die Parteien über Signaturschlüssel verfügen, die zum Signieren von Nachrichten verwendet werden, wodurch im Gegensatz zum einfachen Diffie-Angriff Minimierungssicherheit gegen Man-in-the-Middle-Angriffe geboten wird. Hellman-Methode ohne solche Erweiterungen.
  • Langfristige private/öffentliche Schlüssel sind ED25519-Schlüssel und werden nur zu Signierungszwecken verwendet
• Vorwärtsgeheimnis unter Verwendung der ephemeren Diffie-Hellman-Kurve (Kurve 25519)
  • Dies hat unter anderem zur Folge, dass jede Verbindung auf beiden Seiten immer neue unterschiedliche private und öffentliche Kurzzeitschlüssel und damit auch neue gemeinsame geheime Kurzzeitschlüssel besitzt
  • Kurzfristige private/öffentliche Schlüssel sind X25519-Schlüssel und der kurzfristige gemeinsame geheime Schlüssel wird nur für AEAD-basierte Verschlüsselungszwecke verwendet
• Authenticated Encryption with Associated Data (AEAD)-Paketverschlüsselung
  • Basierend auf ChaCha20 als Verschlüsselung und Poly1305 als kryptografischem Nachrichtenauthentifizierungscode
• Wiedergabeschutz von Anwendungspaketdaten
  • Basierend auf verschiedenen Schutzmechanismen in der Phase des Verbindungsaufbaus und verschlüsselten Paketsequenznummern
• Mechanismus zum verzögerten Verbindungsaufbau als zusätzlicher Mechanismus zur Minimierung der Angriffsfläche
• Verbindungs- und Authentifizierungstoken (als optionale Option, wobei Sie über einen separaten Out-of-Band-Kommunikationskanal verfügen sollten, beispielsweise ein HTTPS-basiertes Master-Backend, um diese Dinge zu generieren und zu verarbeiten) als zusätzlicher Mechanismus zur Minimierung der Angriffsfläche gegen DDoS-Verstärkung Angriffe
  • Verbindungstoken werden im Klartext übertragen, sodass sie beim ersten Datenpaket eines Verbindungsversuchs schnell überprüft werden, ohne dass das Verbindungstoken zuerst entschlüsselt werden muss, bevor eine Überprüfung des Tokens möglich ist Sparen Sie an dieser Stelle CPU-Zeit. Diese Option ist in erster Linie für den Einsatz gegen DDoS-Amplification-Angriffe gedacht, was bedeutet, dass der Server nicht sofort antwortet, wenn das Verbindungstoken beim ersten Datenpaket eines Verbindungsversuchs nicht übereinstimmt, und DDoS-Amplification-Angriffe somit einfach ins Stocken geraten würden Nichts. Folglich sollten diese Token nur für einen kurzen Zeitraum gültig sein, was auch für die Master-Backend-Seite Ihrer Infrastruktur gilt.
  • Authentifizierungstoken werden verschlüsselt übertragen, nachdem der private/öffentliche Schlüsselaustausch, die Generierung des gemeinsamen geheimen Schlüssels usw. erfolgreich durchgeführt wurden. Authentifizierungstoken sind im Gegensatz zum Verbindungstoken KEINE Gegenmaßnahme gegen Angriffe der DDoS-Kategorie, sondern Authentifizierungstoken dienen, wie der Name schon sagt, nur der separaten Out-of-Band-Kommunikationskanalauthentifizierung, also als zusätzlicher Zweck Schutz vor unbefugten Verbindungen, bei dem Sie es auf der Master-Backend-Seite Ihrer Infrastruktur detaillierter überprüfen können, bevor der „Client“ eine Verbindung zum echten Server herstellen kann, auf dem alle eigentlichen Aktionen stattfinden.
• Begrenzer der Verbindungsversuchsrate
  • Konfigurierbar mit zwei Konstanten, Burst und Periode
• Konfigurierbarer Bandbreitenratenbegrenzer
• Optionale virtuelle Netzwerkfunktion (z. B. für eine schnelle lokale Loopback-Lösung ohne Netzwerk-API für Einzelspieler-Spiele, die weiterhin auf dem Server/Client-Konzept basieren sollte)
• Netzwerkinterferenzsimulator (z. B. für Testfälle usw.)
  • Konfigurierbare simulierte Paketverlustwahrscheinlichkeit (jeweils für eingehende und ausgehende Pakete)
  • Konfigurierbare simulierte Latenz (jeweils für eingehende und ausgehende Pakete)
  • Konfigurierbarer simulierter Jitter (jeweils für ein- und ausgehende Pakete)
  • Konfigurierbare simulierte Wahrscheinlichkeit doppelter Pakete (jeweils für eingehende und ausgehende Pakete)
• Mechanismus zur Anpassung der Schwierigkeit der dynamischen Verbindungsherausforderung und Anforderungsantwort
  • Konfigurierbar mit einem Faktorwert
  • Basiert auf einem Bestimmungsmechanismus im History-Smoothing-Frames-per-Second-Stil, aber anstelle von Frames pro Sekunde und Verbindungsversuchen pro Sekunde
• Weitere Komprimierungsalgorithmen zur Auswahl
  • Deflate (ein zlib-Bitstream-kompatibler LZ77- und kanonischer Huffman-Hybrid, nur Fixed-Static-Canonical-Huffman in dieser Implementierung hier auf der Kompressorseite, aber die Dekomprimiererseite ist voll funktionsfähig)
  • LZBRRC (ein Kompressor im LZ77-Stil zusammen mit einem Entropiebereichscodierer-Backend)
  • BRRC (ein Entropiebereichskodierer reiner Ordnung 0)
• CRC32C statt CRC32 (ohne C am Ende)
• Und noch viel mehr. . .

Geplante Funktionen (auch bekannt als Todo) in zufälliger Reihenfolge der Prioritäten

• TODO

Allgemeine Richtlinien für Code-Mitwirkende

Allgemeine Richtlinien für Code-Mitwirkende

Lizenz

zlib-Lizenz

IRC-Kanal

IRC-Kanal #rnl auf Freenode

Danke

• Vielen Dank an Lee Salzman für ENet als Inspiration für die Ideen zur Implementierung des Basis-API-Designs
• Vielen Dank an Glenn Fiedler für die Inspiration für sicherheitsorientierte Umsetzungsideen
• Vielen Dank an Sergey Ignatchenko („No Bugs“ Hare) für die Inspiration auch für sicherheitsorientierte Umsetzungsideen