警告
暗号化コードを含む RNL はこれまでのところ監査されていないため、RNL は重要なデータを含む処理を行わないリアルタイム ゲームとマルチメディア アプリケーションのみを対象としていますが、重要なデータを含む本格的なアプリケーションは対象としていません。
説明
RNL は「リアルタイム ネットワーク ライブラリ」の略です
RNL は、ENet、yojimbo、libgren などからインスピレーションを得た、リアルタイム アプリケーションおよびゲーム用の UDP ベースのネットワーク ライブラリです。
RNL は、リアルタイム ゲームで使用される一般的なパターンを中心に設計されており、シミュレーションに依存し、I/O に依存せず、完全にステートフルであるため、非同期 IO はあまり意味がありません。したがって、RNL コア設計はマルチスレッドではなくシングルスレッドです。ただし、複数の異なるスレッド内で複数の TRNLHost インスタンス (1 つのスレッドあたり 1 つから非常に少数のインスタンス) を使用できるため、この 1 台のマシンが複数のホストをホストするのに十分な強度と速度を備えている限り、同じマシンで複数のネットワーク ゲームの試合をホストできます。ネットワークゲームも同時に対戦できます。
そして、ゲームクライアント側では、干渉やその他の同様の問題が少ないように、可能であればネットワーク全体を独自の (可能であれば CPU コアに固定された) スレッドで実行する必要があります。 (余談: 適切な時点で十分な CPU 時間を取得できなかった場合に、オーディオ バッファ アンダーランの問題などが発生する可能性がある場合を除き、同じことがオーディオ スレッドにも当てはまります。:-))
また、単一のゲーム ワールド内に多数のクライアントがある大規模なゲームの場合は、複数の細分化された TRNLHost インスタンスを使用して、各 TRNLHost が少数の接続されたクライアントのみを複数のスレッドで処理し、複数の物理専用サーバー上で処理する必要があります。相互に通信して、単一の非常に大きなゲーム世界の印象を模倣する場合があります。少なくとも 1 つの TRNLHost インスタンスは、エゴシューターやレーシング ゲームなどの一般的なクライアント数が少ない場合に向けて設計されています。言い換えると、多数のクライアントを持つ大規模なゲーム ワールドの場合: 分割統治 (たとえば、分割統治の概念アイデアの一例として、ゲーム ワールドのセクターの境界が部分的に重なっているなど)
サポートしてください
Patreonでサポートしてください
特徴
- ほとんどが完全なオブジェクト指向のコード設計
- IPv6のサポート
- クロスプラットフォーム
- Windows (FreePascal および Delphi を使用)
- Linux (FreePascal を使用)
- *BSD (FreePascal を使用)
- Android (FreePascal および Delphi 搭載)
- Darwin (MacOS(X) および iOS) (FreePascal および Delphi を使用)
- UDPベースのプロトコル
- シーケンス
- チャンネル
- 次のような自由に構成可能なチャネル タイプがあります。
- 信頼できる注文
- 信頼性の高い順序なし
- 信頼性の低い注文
- 信頼性が低く、順序付けられていない
- 信頼性
- 断片化と再構築
- 集計
- 適応性
- 携帯性
- 純粋なクライアント/サーバー モデルのみの代わりに、ピアツーピア モデル、またはピアツーピアとクライアント/サーバーの混合モデルを使用する可能性。もちろん、従来のクライアント/サーバー モデルも使用可能
- 暗号的に安全な擬似乱数生成器 (CSPRNG)
- arc4random に基づいていますが、基本的な構成要素として代わりに ChaCha20 を使用した RC4
- 複数のエントロピー ソース (バックドアがある可能性があるため、単一のエントロピー ソースを決して信頼してはなりません)
- これらの命令が現在実行中のプロセッサでサポートされている場合、オプションの追加の疑似ハードウェア ベースのエントロピー ソースとして、新しい x86 プロセッサでの rdseed/rdrand 命令の使用が含まれます。
- 相互認証
- ステーション間 (STS) のようなプロトコルに基づいており、当事者がメッセージの署名に使用される署名キーを持っていることを前提としているため、基本的な単純な Diffie とは異なり、中間者攻撃に対する縮小セキュリティが提供されます。そのような拡張機能を持たない Hellman メソッド。
- 長期秘密鍵/公開鍵は ED25519 鍵であり、署名目的のみに使用されます。
- 楕円曲線エフェメラル Diffie-Hellman を使用した前方秘匿性 (曲線 25519)
- 他の事実に基づくこの結果は、各接続には常に両側に新しい異なる秘密および公開短期キーがあり、したがって新しい共有秘密短期キーも存在することになります。
- 短期秘密鍵/公開鍵は X25519 鍵であり、短期共有秘密鍵は AEAD ベースの暗号化の目的でのみ使用されます。
- Authenticated Encryption with Associated Data (AEAD) パケット暗号化
- 暗号として ChaCha20、暗号メッセージ認証コードとして Poly1305 に基づく
- アプリケーションパケットデータのリプレイ保護
- 接続確立段階でのさまざまな保護メカニズムと暗号化されたパケット シーケンス番号に基づく
- 追加の攻撃対象領域縮小メカニズムとしての遅延接続確立メカニズム
- DDoS 増幅に対する追加の攻撃対象領域を縮小するメカニズムとしての接続および認証トークン (オプションとして、別の帯域外通信チャネル (たとえば、このようなものを生成および処理するための HTTPS ベースのマスター バックエンド) が必要です)攻撃
- 接続トークンはクリア テキストで転送されるため、接続試行による最初のデータ パケットで高速にチェックされます。トークンをチェックする前に接続トークンを復号化する必要はありません。この時点で CPU 時間を節約します。このオプションは主に DDoS 増幅攻撃に対して使用するためのものです。つまり、接続試行による最初のデータ パケットで接続トークンが一致しない場合、サーバーはすぐに応答しないため、DDoS 増幅攻撃は単純に何もない。したがって、これらのトークンは短期間のみ有効である必要があり、これはインフラストラクチャのマスター バックエンド側にも当てはまります。
- 認証トークンは、秘密鍵/公開鍵の交換、共有秘密鍵の生成などが正常に処理された後、暗号化されて転送されます。接続トークンとは対照的に、認証トークンは DDoS カテゴリの攻撃に対する対抗手段ではありません。むしろ認証トークンは、その名前が示すように、別個の帯域外通信チャネルの認証目的のみ、つまり追加の目的で使用されます。不正な接続に対する保護。「クライアント」が実際のサーバーに接続する前に、インフラストラクチャのマスター バックエンド側で詳細にチェックできます。実際のサーバーではすべてのアクションが行われます。
- 接続試行レート リミッター
- 構成可能な帯域幅レート リミッター
- オプションの仮想ネットワーク機能 (たとえば、シングルプレイヤー ゲームの試合用の高速ネットワーク API レスのローカル ループバック ソリューション。これは依然としてサーバー/クライアントの概念に基づいている必要があります)
- ネットワーク干渉シミュレーター (テストケースなど)
- 設定可能なシミュレートされたパケット損失確率 (受信パケットと送信パケットごと)
- 設定可能なシミュレートされた遅延 (受信パケットと送信パケットごと)
- 設定可能なシミュレートされたジッター (受信パケットと送信パケットごとに)
- 設定可能なシミュレートされた重複パケット確率 (受信パケットと送信パケットごと)
- 動的接続チャレンジ要求応答難易度調整メカニズム
- 係数値で構成可能
- History-smoothing-frames-per-sec スタイルの決定メカニズムに基づいていますが、代わりに 1 秒あたりのフレーム数、1 秒あたりの接続試行数に基づいています。
- より多くの圧縮アルゴリズムを選択可能
- Deflate (zlib ビットストリームと互換性のある LZ77 と正規ハフマンのハイブリッド、この実装では圧縮側では fix-static-canonical-huffman のみですが、解凍側はフル機能です)
- LZBRRC (エントロピー範囲コーダー バックエンドを備えた LZ77 スタイルのコンプレッサー)
- BRRC (純粋な次数 0 エントロピー範囲コーダー)
- CRC32 の代わりに CRC32C (末尾に C なし)
- 他にもたくさんのものがあります。 。 。
ランダムな優先順位で計画された機能 (別名 Todo)
コード寄稿者向けの一般的なガイドライン
コード寄稿者向けの一般的なガイドライン
ライセンス
zlibライセンス
IRCチャンネル
Freenode の IRC チャネル #rnl
ありがとう
- 基本 API 設計の実装アイデアのインスピレーションとなった ENet の Lee Salzman に感謝します。
- セキュリティ指向の実装アイデアのインスピレーションを与えてくれた Glenn Fiedler に感謝します
- セキュリティ指向の実装アイデアについてもインスピレーションを与えてくれた Sergey Ignatchenko ("No Bugs" Hare) に感謝します