Bolt Packets
最初にネットワーキングにアプローチする際、それぞれのイベント、またはそれぞれの変化が、ネットワークを介して送信される別のパケットとして発生することを想定しています。ボルト(またはその他の業界のアクションゲーム)ではこのようにはいきません。Bolt は、Bolt の設定で指定された Send Rate
に基づいてパケットをパックアップします (デフォルトでは 1 秒に 20 回です)。つまり、デフォルトの設定では、Boltは3回のシミュレーションティック(つまりFixedUpdate
ティック)ごとにパケットをネットワーク経由で各接続に送信します(20パケット/秒)。この場合の設定は 3
であり、パケットを送信する前に何回シミュレーションティックが発生するかを表しています。ボルトは、MTU下に必要な単一のパケットにすべてをパックします。これには、イベントや状態の更新、コマンド入力(クライアントからの)結果(サーバからの)結果、プロキシの作成/破棄、すべてのものが含まれます(ストリーミングを除く)。そのため、サーバーからの1秒あたりの最大発信バンド幅は以下のようになります。
latex
MaxBandwidth = SendRate * MaxPacketSize * NumPlayers;
ここで、MaxPacketSize
はBolt Settingsで定義されており(Maximum Transmission Unitの下になければなりません)、NumPlayers はサーバに接続しているプレイヤーの数です(サーバにインゲームプレイヤーがいる場合は+1)。
Boltは相手側でパケットの組み換えを行わないため、断片化されたパケットを扱うことができません。つまり、パケットサイズはMaximum Transmission Unit以下でなければなりません。これは一般的な方法です。しかし、これはBoltがそのパケットに収まるものを優先しなければならないことを意味します(多くの場合、すべてを収めることはできないため)。これは、多くの同期トランスフォームを持っている場合に悪化する可能性があります。重くなり、強く圧縮されていても、1つあたり~20バイト以上のバイトを使用するためです(ネットワークIDなどのオーバーヘッドもあります)。そこで、プロパティの優先度が活用されます (また、IPriorityCalculator
)。データやプロパティ圧縮の重要度をBoltに伝えることができます。状態のプロパティは、その優先度番号が大きいほど、優先度が高いとみなされます。つまり、優先度50の場合、優先度1よりも優先度が高くなります。プロパティが送信されていないことを示す送信ティックごとに、Boltはダーティなプロパティの優先度を1つずつ増加させます。送信されるデータ量に応じて、エンティティ内の他のプロパティよりもはるかに高い優先度を持つエンティティ内のプロパティが多すぎると、多くの送信ティックのために他のプロパティを空にしてしまう可能性があるため、プロパティの優先度の割り当て方には注意が必要です。また、Bolt は Max Properties Per Packet プロパティ(Bolt Settings)のみをパックします。この制限に達すると、次のエンティティを変更してパッキングするために移動します。
Boltには、優先度の低い状態のプロパティが最終的にパケットに入ることを保証するステイルネス修飾子もあります(それらがスキップされ、現在のパケットに作ることができないたびに、その優先度を高めることによって)。
イベントはこの単一のパケットにパックされているので(別々に送信されない)、信頼性の低いイベントもこのパックに含まれています。 Boltは、イベントをドロップする前に、2回パケットに信頼性の低いイベントを適合させようとします。
Boltの各接続は、4つの内部チャンネルを実装しています。それらは次のとおりです。
- シーン読み込みチャンネル
- コマンド チャンネル
- イベント チャンネル
- 状態 チャンネル
各チャンネルは#1から#4まで順番にパッキングされます。パケットが送信ティックのためのスペースを使い果たした場合、パケットのパッキングは停止します。これはイベントが常にステートよりも優先されることを意味します。つまり、一度に多くのイベントを送信すると、その送信ティックの状態データのためにパケットを空にすることができます。シーン読み込みチャンネルはあまり使われていませんが、新しい接続のためのハンドシェイクコールバックの一部などで使用されています。
Back to top