これは、最新のRakNetプロトコルドキュメントです。プロトコルで使用されるデータ型に関する情報と、各パケットとそれらに関連するフィールドに関する詳細が含まれます。
TODO:変更して、目の方が改善し、多くの役に立たないものを削除します。また、1つの場所でenums/定数などのものを整理し、繰り返しのものを削除します。
このドキュメントでは、Libcatの類似/同じセキュリティ方法が必要な場合があります。そのため、ターゲットをターゲットにしているサーバーにLibcatまたはそれと同じものがない場合、セキュリティが有効になっている場合、クライアントはCookie、Identity Proof、またはNothingのみを提供するためにクラッシュします。ただし、両方のケースをサポートするリクエストを引くことができます。
| タイプ | サイズ | 注記 |
|---|---|---|
| uint8 | 1バイト | 署名されていない8ビット整数 |
| UINT16 | 2バイト | 署名されていない16ビット整数 |
| uint24 | 3バイト | 最小値は0、最大値は16777215の署名されていない24ビット整数 |
| UINT32 | 4バイト | 署名されていない32ビット整数 |
| UINT64 | 4/8バイト | 署名されていない64ビット整数(32ビットシステムの4バイト、64ビットシステムで8バイト) |
| uint16-string | 変数 | 文字列の前に2バイトの長さのUTF-8エンコード文字列 |
| 魔法 | 16バイト | 特定のシーケンス[0x00, 0xFF, 0xFF, 0x00, 0xFE, 0xFE, 0xFE, 0xFE, 0xFD, 0xFD, 0xFD, 0xFD, 0x12, 0x34, 0x56, 0x78]を持つ、符号なしの8ビット整数の配列 |
| ゼロのパッド | 変数 | 選択したサイズのパディングに使用されるヌルバイト |
| ブール | 1バイト | 0または1の値を持つ単一の署名されていない8ビット整数として書くか読み取ります(ゼロはfalseを表すために使用され、1つは真の表現に使用されます) |
| 住所 | 7-29バイト | IPv4:1バイト(アドレスバージョン)、4バイト(IPアドレス)、2バイト(ポート)、IPv6:1バイト(アドレスバージョン)、アドレスファミリ(リトルエンディアン)の符号なし略、ポート番号の符号なし、フロー情報用の符号なし整数、アドレスの16バイト、範囲IDの非署名されたインテル。 |
| 少し | 1ビット | あなたがそれを完了した後、バッファー内のビットを書くか読む |
| フロート | 4バイト | IEEE 754シングルエシジョンフローティングポイント番号 |
実装をより速くしたい場合、それらがどのように作られたかを読むことなく、それらを即座に定義できます。
| 名前 | 価値 |
|---|---|
| mtusize | 1492 |
| udpheadersize | 28 |
| publicKeysize | 294 |
| requstchallengesize | 64 |
| ResponsingEncryptionKey | 128 |
| MaxNumberofLocalAddresses | 10 |
| IDPROOFSIZE | 294 |
| clientProofsize | 32 |
| DefaultProtocolversion | 6 |
| numberofarrangedStreams | 32 |
| 名前 | id | タイプ |
|---|---|---|
| 接続なし | 0x01 | オフライン |
| unconectedpenconnections | 0x02 | オフライン |
| unnectedpong | 0x1c | オフライン |
| コネクテッド | 0x00 | オンライン[from/to Datagram] |
| ConnectedPong | 0x03 | オンライン[from/to Datagram] |
| OpenConnectionRequestone | 0x05 | オフライン |
| OpenConnectionReplyone | 0x06 | オフライン |
| OpenConnectionRequesttwo | 0x07 | オフライン |
| OpenConnectionReplytwo | 0x08 | オフライン |
| ConnectionRequest | 0x09 | オンライン[from/to Datagram] |
| RemoteSystemRequiRespublickey | 0x0a | オフライン |
| OursystemRequiressecurity | 0x0b | 両方 [?] |
| ConnectionAttemptFailed | 0x11 | オフライン |
| すでに接続されています | 0x12 | オフライン |
| ConnectionRequestaceded | 0x10 | オンライン[from/to Datagram] |
| newincomingConnection | 0x13 | オンライン[from/to Datagram] |
| 切断解釈 | 0x15 | オンライン |
| ConnectionLost | 0x16 | 両方 [?] |
| 互換性のないプロトコルバージョン | 0x19 | オンライン |
クライアントからの接続されていないパケットを待ちます。
クライアントからのOpenConnectionRequestoneパケットを待ちます。
クライアントからのOpenConnectionRequestTwoパケットを待ちます。
クライアントからのデータグラムを待ちます。
接続されていないパケットをサーバーに送信します。
OpenConnectionRequestoneパケットをサーバーに送信します。
サーバーにopenconectionRequestTwoパケットを送信します。
データグラムをサーバーに送信します。
このパケットは、サーバーがオンラインであるかどうかを判断するために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| 唯一のreplyonopenconections | ブール | n/a | TRUEに設定されている場合、サーバーは現在開いているサーバーへのクライアントの接続が現在開いている場合にのみ返信を送信します。これは、接続を閉じたクライアントに応答を送信するのを防ぐのに役立ちます。リクエストの結果のメッセージIDは、 UnconnectedPingOpenConnectionsます。 falseに設定した場合、識別子を変更する必要はありません。 |
| id | uint8 | n/a | パケットの一意の識別子 |
| clientsendtime | UINT64 | ビッグエンディアン | レイテンシの計算に使用されるクライアントタイムスタンプ |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
このパケットは、接続されていないpingパケットへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| ServerSendTime | UINT64 | ビッグエンディアン | レイテンシの計算に使用されるサーバータイムスタンプ |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| Ressiondata | uint16-string | ビッグエンディアン | 通常、サーバー情報に使用される応答データ |
このパケットは、クライアントとサーバー間の接続を生かし続けるために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| clientsendtime | UINT64 | ビッグエンディアン | レイテンシの計算に使用されるクライアントタイムスタンプ |
このパケットは、接続されたpingパケットへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| clientsendtime | UINT64 | ビッグエンディアン | pingのクライアントタイムスタンプ |
| ServerSendTime | UINT64 | ビッグエンディアン | レイテンシの計算に使用されるサーバータイムスタンプ |
このパケットは、クライアントとサーバー間の握手プロセスを開始するために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| プロトコルバージョン | uint8 | n/a | クライアントがサポートするプロトコルバージョン |
| mtusize | ゼロのパッド | n/a | クライアントの最大トランスミッションユニット(MTU)サイズ |
Pad-with-zeroを使用する場合は、MTUサイズに現在の読み取り位置と、読み取りのために28(UDPヘッダーサイズ)を追加します。書き込みの場合は、MTUサイズを現在のバッファライティング位置(またはそのサイズ)と28(UDPヘッダーサイズ)と現在のバッファサイズで差し引いてください。パケットバッファーを検証するには、そのサイズが28(UDPヘッダーサイズ)と現在のバッファサイズであるかどうかを確認します。
このパケットは、Open Connection Request Oneパケットへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
| ServerHasseCurity | ブール | n/a | サーバーがセキュリティを必要とするかどうか |
| mtusize | UINT16 | ビッグエンディアン | サーバーの最大送信ユニット(MTU)サイズ |
このパケットは、追加のセキュリティ情報を含むOpen Connection Request Oneパケットへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
| ServerHasseCurity | ブール | n/a | サーバーがセキュリティを必要とするかどうか |
| HasCookie | ブール | n/a | パケットにCookieが含まれているかどうか |
| クッキー | UINT32 | ビッグエンディアン | クッキー値 |
| serverpublickey | uint8 [294] | n/a | 暗号化に使用される公開鍵 |
| mtusize | UINT16 | ビッグエンディアン | サーバーの最大送信ユニット(MTU)サイズ |
このパケットは、クライアントとサーバー間の握手プロセスを完了するために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| ServerAddress | uint8 [7-29] | n/a | サーバーIPアドレスとポートコンボ |
| mtusize | UINT16 | ビッグエンディアン | クライアントの最大トランスミッションユニット(MTU)サイズ |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
このパケットは、クライアントとサーバー間の握手プロセスを完了するために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| クッキー | UINT32 | ビッグエンディアン | クッキー値 |
| containschallenge | ブール | n/a | システムに握手の課題が必要かどうか |
| チャレンジ | UINT8 [64] | n/a | システムハンドシェイクチャレンジバイト |
| ServerAddress | uint8 [7-29] | n/a | サーバーIPアドレスとポートコンボ |
| mtusize | UINT16 | ビッグエンディアン | クライアントの最大トランスミッションユニット(MTU)サイズ |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
注:OpenConnectionReplyoneパケットにセキュリティがあるが、このパケットに課題が含まれていない場合、クライアントはすぐにRemoteSystemRequireSpublickeyパケットを送信して、OpenConectionRequestTWOパケットに課題がないことをサーバーに通知する必要があります。
接続結果を計算する独自の方法を作成できますが、これは標準的な方法です。
ConnectionOutcomeの計算:
bitwise and以下contains addressチェックcontains guid必要かどうかを確認します。clientGuidが既に異なるクライアントアドレスを持つクライアントに関連付けられている場合、接続状態を3に設定します。clientGuidに関連付けられている場合、接続状態を4に設定します。
ConnectionOutcomeを計算したら、それが1に等しいかどうかを確認する必要があります。その後、OpenConnectionReplyTwoパケットを送信します。
ConnectionOutcomeが0でない場合は、AlreadyConnectedパケットを送信します。
このパケットは、Open Connection Request Two Packetへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
| ClientAddress | uint8 [7-29] | n/a | クライアントIPアドレスとポートコンボ |
| mtusize | UINT16 | ビッグエンディアン | サーバーの最大送信ユニット(MTU)サイズ |
| 必要なクリップ | 少し | n/a | 接続に暗号化が必要かどうか |
| encryptionKey | UINT8 [128] | n/a | クライアントの暗号化キー - requiresEncryptionフィールドがtrueに設定されている場合にのみ、書き込まれるか読み取りされます。 |
このパケットは、セキュリティが有効または無効になっているクライアントとサーバーの間の接続を確立するために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
| clientsendtime | UINT64 | ビッグエンディアン | 接続することを要求したときのクライアントのタイムスタンプ |
| dosecurity | ブール | n/a | 接続にセキュリティが必要かどうか |
| クライアントプルーフ | UINT8 [32] | n/a | クライアント認証の証明 |
| dodoidentity | ブール | n/a | パケットに身元証明が必要かどうか |
| IDPROOF | uint8 [294] | n/a | クライアントアイデンティティの証明 |
注:IDの証明が無効で、
doIdentityがtrueに設定されている場合は、すぐにClientIdentityIsInvalidのタイプIDを備えたRemoteSystemRequiresPublicKeyパケットを送信します。doIdentityがfalseに設定されていて、IDの証明がない場合は、RemoteSystemRequiresPublicKeyパケットをClientIdentityIsMissingのタイプIDで送信します。
このパケットは、クライアント認証と識別のための公開キー要求に関連するエラーをスローするために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| TypeID | uint8 | n/a | 公開キーリクエストの種類 |
| 名前 | id |
|---|---|
| serverpublickeyismissing | 0 |
| clientidentityismissing | 1 |
| clientidentityisinvalid | 2 |
このパケットは、サーバーがセキュリティを必要としないときに送信されますが、それでも必須です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| ClientAddress | uint8 [7-29] | n/a | クライアントIPアドレスとポートコンボ |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
このパケットは、サーバーに参加しようとする試行カウントが特定の金額よりも高い場合(実装に依存します)、クライアントに割り当てられたアドレスが含まれていない場合に送信されます。これは、 OpenConnectionRequestOneパケットを送信する前に要件が満たされている場合にチェックして送信するものです。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
このパケットは、クライアントがすでに接続されているときに送信されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
このパケットは、セキュリティが有効になっている接続要求への応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| ClientAddress | uint8 [7-29] | n/a | クライアントIPアドレスとポートコンボ |
| clientIndex | UINT16 | ビッグエンディアン | クライアントに割り当てられた一意の識別子 |
| serverMachIneadDresses | 住所[10] | n/a | サーバーローカルマシンアドレス |
| clientsendtime | UINT64 | ビッグエンディアン | クライアントのためのタイムスタンプ |
| ServerSendTime | UINT64 | ビッグエンディアン | サーバーのタイムスタンプ |
このパケットは、新しいクライアントがサーバーに接続すると、他のすべてのクライアントに送信されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| ServerAddress | uint8 [7-29] | n/a | サーバーIPアドレスとポートコンボ |
| clientMachIneadDresses | 住所[10] | n/a | クライアントローカルマシンアドレス |
| clientsendtime | UINT64 | ビッグエンディアン | クライアントのためのタイムスタンプ |
| ServerSendTime | UINT64 | ビッグエンディアン | サーバーのタイムスタンプ |
このパケットをサーバーに送信または受信した後、定期的なConnectedPingパケットを送信して、接続を生かし続ける必要があります。これらのパケットは、本質的に「ねえ、私はまだここにいて、サーバーに接続している」と言う方法です。また、サーバーは、接続がまだアクティブであることを確認するために、 ConnectedPongパケットを返信します。このPing-Pongプロセスは、非アクティブまたはネットワークの問題により、接続のタイミングが停止するのを防ぐのに役立ちます。
このパケットは、クライアントがサーバーから切断されたときに送信されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
このパケットは、クライアントへの接続が失われたときに送信されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| clientGuid | UINT64 | ビッグエンディアン | クライアント用の一意の識別子 |
| ClientAddress | uint8 [7-29] | n/a | クライアントIPアドレスとポートコンボ |
このパケットは、クライアントが互換性のないプロトコルバージョンを使用してサーバーに接続しようとするときに送信されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| プロトコルバージョン | uint8 | n/a | サーバーでサポートされているプロトコルバージョン |
| 魔法 | uint8 [16] | n/a | パケットを識別するマジックシーケンス |
| serverGuid | UINT64 | ビッグエンディアン | サーバーの一意の識別子 |
このパケットは、クライアントとサーバー間でデータの送信と受信に使用されます。 validdatagram、ackeddatagram、またはnackeddatagramの3つのタイプのいずれかの1つになります。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| isvalid | 少し | n/a | 常に真です |
| isack | 少し | n/a | 本当なら、パケットはAckedDatagramです |
| イスナック | 少し | n/a | 本当なら、パケットはnackeddatagramです |
isAckとisNackが両方とも虚偽の場合、パケットはvalidDatagramです。
このパケットは、サーバーがデータを受信したことを示すvalidDatagramへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| bandasが必要です | 少し | n/a | Trueの場合、パケットにはBおよびAS値が含まれます |
| b | フロート | ビッグエンディアン | 使用されていません |
| として | フロート | ビッグエンディアン | データの到着率 |
| 範囲 | 範囲 | n/a | 受信された範囲値の配列 |
このパケットは、サーバーが予想されるすべてのデータを受信していないことを示すvalidDatagramへの応答です。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| 範囲 | 範囲 | n/a | 受信されなかった範囲値の配列 |
この構造は、AckedDatagramsの範囲とNackedDatagramsの欠落範囲を表すために使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| サイズ | UINT16 | ビッグエンディアン | 配列の範囲数 |
| Issingle | ブール | n/a | minが最大に等しい場合、これはtrueに設定されています |
| 分 | uint24 | リトルエンディアン | 範囲の最小値 |
| マックス | uint24 | リトルエンディアン | 範囲の最大値 - 単一である場合は書かれていません |
このパケットは、クライアントとサーバー間でデータの送信と受信に使用されます。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| ispacketpair | 少し | n/a | 本当なら、パケットは2つの関連パケットの1つです |
| iscontinuoussend | 少し | n/a | Trueの場合、パケットは連続送信パケットです |
| bandasが必要です | 少し | n/a | Trueの場合、パケットにはBおよびAS値が含まれます |
| rangeNumber | uint24 | リトルエンディアン | データグラムのシーケンス番号 |
| カプセル | datagramcapsule [] | n/a | パケット内のカプセルの配列 |
破損したアレンジメントチャネルのチェック:(有効なデータグラムは「シーケンスとアレンジ)する必要があります(ACK領収書なし))
arrangmentChannelが大きい場合、または2 ^ 5の利用可能なアレンジストリームの数に等しい場合、それは回復されます(スキップして必要なことを行います)。
すべての有効なデータグラム配置タイプの配列最大値は、アレンジされたストリームの数であり、大きくなってはなりません。
受信したデータグラムでホールカウントを見つける:(有効なデータグラムは、さらに進む前にReliable or in sequenceばなりません)
Reliable or in sequenceある有効なデータグラムでホールカウントを確認する必要があります。その理由は、注文をチェックするためであり、送信または他の理由で受信または間違ったrangeNumberが使用されているかどうか、ある種の有効なデータグラムがあるかどうかをチェックとして機能します。
receivedPacketsBaseIndex :有効なデータグラムがReliable or in sequence増加します
receivedPacketQueue :有効なデータグラムのrangeNumberリストのキーとして保存するものであり、値はデータグラムではなく価値があり、誤っている可能性がありますが、以下に記載されているDS_Queueかのコードを満たした後、誤っていることは、それが成功しなかったことを意味します)。
ホールカウントを見つけるために、受信した有効なデータグラムのrangeNumber receivedPacketsBaseIndexを使用して、そのプロパティがホールカウントがないたびにそのプロパティ増分( receivedPacketsBaseIndex Reliable or in sequence増加する場合にのみ増加します)。
receivedPacketQueueから削除して、 receivedPacketsBaseIndexインデックスを追加(事前)増加させます。bitwise right shifted uint24の最大値よりも大きい場合、それは複製されたパケットです(スキップして必要なことを実行します)。receivedPacketQueueサイズよりも小さい場合receivedPacketQueueのインデックス/キーであり、falseに等しくない場合、 receivedPacketQueueのホールカウントのキーを、値がfalseに等しいというキーに置き換えることにより、穴を埋めます。述べられたこれらの条件が満たされなかった場合:
bitwise and uint32最大値)がreceivedPacketQueueサイズよりも大きい場合は、キューで真の値を押して満たします。その後、ループを作成して、 receivedPacketQueueサイズが0より大きく、 receivedPacketQueueの最初の値がfalseであるかどうかを確認し、 receivedPacketQueueの最後の要素を削除してから、 receivedPacketsBaseIndexを増加させます。
その後、有効なデータグラムを正常に処理できます。
この構造は、validdatagramのカプセルを表します。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| 信頼性 | 3ビット | ビッグエンディアン | 使用される信頼性のタイプ |
| ISSEGEMED | 少し | n/a | Trueの場合、パケットはセグメント化されています |
| サイズ | UINT16 | ビッグエンディアン | そこにあるバッファフィールドのサイズがビットで |
| reliablecapsuleindex | uint24 | リトルエンディアン | 信頼できるパケットに使用されるインデックス(これは信頼性を使用することを意味します) |
| SequencedCapsuleIndex | uint24 | リトルエンディアン | シーケンスされたパケットに使用されるインデックス(これは信頼性を使用することを意味します) |
| 配置 | CapSulearRangement | n/a | シーケンスおよびアレンジされたパケットに使用されるカプセルの配置(これは信頼性を使用することを意味します) |
| セグメント | カプセルセグメント | n/a | カプセルがセグメント化されたときに使用されるカプセルのセグメント |
| バッファ | バッファ | n/a | データを含むバッファデータは、ネットワークを介して送信されたいと考えていました |
この構造は、validDatagram内のカプセルの配置を表しています。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| ArrangedCapsuleIndex | uint24 | リトルエンディアン | 配置されたカプセルのインデックス |
| ArractionChannel | uint8 | n/a | アレンジメントに使用されるチャネル |
この構造は、validDatagramでのカプセルのセグメンテーションを表しています。
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| サイズ | UINT32 | ビッグエンディアン | セグメントのサイズ |
| id | UINT16 | ビッグエンディアン | セグメントに関連付けられた一意の識別子 |
| 索引 | UINT32 | ビッグエンディアン | セグメントのインデックス |
Raknetで送信された各データグラムには、プロトコルによってデータの処理方法を指定する信頼性TypeIDが割り当てられます。次の表には、利用可能な信頼性TypeIDとそのプロパティを示します。
| 名前 | id | 信頼できます | 配置されています | シーケンスされています | 特性/機能 |
|---|---|---|---|---|---|
| 信頼できない | 0 | いいえ | いいえ | いいえ | この信頼性TypeIDは、目的地に到着することを保証することなくデータグラムを送信します。それらは特定の順序で、またはまったく配信されることを保証されていません |
| 非liablesequenced | 1 | いいえ | はい | はい | この信頼性TypeIDは、目的地に到着することを保証することなくデータグラムを送信しますが、送信されたシーケンスで配信されることを保証します |
| 信頼性のある | 2 | はい | いいえ | いいえ | この信頼性TypeIDは、送信された順序で配信されることが保証されているデータグラムを送信します。データグラムが紛失した場合、Raknetは受信機によって認められるまで再送信します |
| reliablearranged | 3 | はい | はい | いいえ | この信頼性TypeIDは、送信された順序で配信されることが保証されているデータグラムを送信します。データグラムが紛失した場合、Raknetはそれを再送信せず、その前にすべてのデータグラムが認められていないことがあります |
| reliablesequeance | 4 | はい | はい | はい | この信頼性TypeIDは、送信された順序で配信されることが保証されているデータグラムを送信し、それらが順次配信されることを保証します |
| 信頼できないwithackreceipt | 5 | いいえ | いいえ | いいえ | この信頼性TypeIDは、宛先に到着することを保証することなくデータグラムを送信しますが、受信者はこのデータグラムの受領時に承認領収書を送信します |
| 信頼できるwithackreceipt | 6 | はい | いいえ | いいえ | この信頼性TypeIDは、送信された順序で配信されることが保証されているデータグラムを送信し、受信者はこのデータグラムの受領時に確認領収書を送信します |
| reliablearRarrangedwithackreceipt | 7 | はい | はい | いいえ | この信頼性TypeIDは、送信された順序で配信されることが保証されているデータグラムを送信しますが、その前に認められていないすべてのデータグラムが送信され、受信者はこのデータグラムの受領時に確認領収書を送信します |
ここでは、ドキュメントの他の場所で使用されるすべての信頼性定義を見つけることができます。
Sequenced 、信頼性のある配置され、ACKレシピットで配置されたときですRaknetは、選択的な繰り返し再送信を使用して、データグラムの信頼できる配信を確保します。データグラムが送信されると、シーケンス番号が割り当てられます。データグラムが特定のタイムアウト期間内に確認されていない場合、Raknetは同じシーケンス番号を使用してデータグラムを再送信します。レシーバーが同じシーケンス番号で重複したデータグラムを受信すると、そのシーケンス番号がすでに認めているため、破棄できます。
Ackqueueとnackqueueは、どのデータグラムが認められており、どのデータグラムが認められていないかを追跡するために使用されます。 Ackqueueには、認識されたことに成功したデータグラムシーケンス番号のリストを保存しますが、Nackqueueは認められておらず、再送信する必要があるデータグラムシーケンス番号のリストを保存します。既に認められているシーケンス番号でデータグラムが受信されると、破棄することができます。
PacketPairは、Raknetがデータグラムの再送信の効率を向上させるために使用する手法です。データグラムが確認されると、Raknetは次のデータグラムもシーケンスで送信します。これにより、受信者は次のデータグラムの処理をすぐに開始し、遅延を減らし、スループットを改善できます。
Continuoursendは、承認を待たずにデータグラムを継続的に送信できるようにするRaknetの機能です。これにより、場合によってはパフォーマンスが向上する可能性がありますが、次のデータグラムを送信する前に送信者がフィードバックを待たないため、パケットの損失と再送信につながる可能性もあります。
Raknetは、再組み立てメカニズムを使用して、順番に受信される可能性のあるセグメント化されたデータグラムを再構築します。データグラムがセグメント化されると、各セグメントに一意の識別子が割り当てられます。受信機がセグメントを受信すると、同じ識別子を持つすべてのセグメントが受信されるまでバッファリングされます。すべてのセグメントが受信されると、それらは元のデータグラムに再組み立てされます。
フロー制御は、送信者と受信機の間のデータ送信率を管理するために使用されるRakNetメカニズムです。これにより、受信者は、処理できるペースで着信データを処理し、受信機のバッファーを圧倒またはオーバーフローさせることができます。フロー制御は、送信者の送信速度と受信機の処理能力のバランスを維持し、通信の全体的な効率と安定性を最適化するのに役立ちます。
渋滞マネージャーは混雑制御を保持し、スキップされた範囲番号をチェックしてNACKなどを送信します。
TODO:ドキュメントを追加します
輻輳制御は、データ送信速度のバランスをとることにより、ネットワーク輻輳を防ぐために使用されるRakNet手法です。 TCPの混雑制御、パケットドロップ、レートの制限、トラフィックシェーピング、QoS、負荷分散などの手法が使用されます。これらの手法により、信頼できるデータ配信とRaknetでの効率的な送信が保証されます。
Raknetのセグメンテーションは、大きなメッセージをより小さなセグメントに分割することにより、データ配信を強化します。これらのセグメントは、位置とサイズを示すヘッダーを使用して、受信者の端で成功した再組み立てを確保します。バッファーサイズを最大透過ユニット(MTU)サイズと比較することにより、バッファーがMTUを超える場合、伝送のセグメントに分割されます。 Raknetのこのメカニズムは、データの損失を防ぎ、大きなペイロードを管理し、ネットワーク化されたアプリケーションでの信頼できる送信を保証します。
「B」は、ネットワークリンク上で1秒あたり送信できるリンク容量またはデータの最大量を表します。リンク容量は、ネットワークインフラストラクチャ、ネットワーク構成、利用可能なリソースなど、複数の要因によって決定されます。フロート値を使用することにより、ネットワーク容量をより正確かつ正確に表現し、利用可能なリソースをより適切に利用できるようにします。
「As」は、データが生成され、送信者によって送信されるレートであるデータの到着率を表します。フロート値を使用すると、到着率をより正確に表現できます。これは、アプリケーションの要件とネットワーク条件に基づいて異なる場合があります。到着率をリンク容量と比較することにより、送信者は、混雑やパフォーマンスの劣化を引き起こすことなく、ネットワークリンクを介して送信できるデータの量を決定できます。
カプセルのサイズを決定するには、次の手順に従うことができます。
reliableCapsuleIndexを表すためにバイトを3ステップで増やします。sequencedCapsuleIndex CapsuleIndexを表すためにバイトを3ステップで増やします。arrangedCapsuleIndexのバイトを3ステップ、次にarrangementChannelの1ステップで増分します。sizeの4つのステップ、 idの2つのステップ、セグメントのindexの4つのステップをインクリメントします。 UserPacketEnum IDは0x86です。これは、カスタムパケットIDの使用を開始できる場所の始まりを示しています。
推奨されるのは、完成した実装があることを考慮して、送信して受信することを考慮して、 PacketAggregatorを作成することです。
次のように、選択したIDを配置できます: UserPacketEnumID + Your's自身のID( UserPacketEnumIDをuint8 limitを上回らないようにしてはなりません)
例: UserPacketEnumID + 22 = 0x9c
PacketAggregator何であるかを示すシンプルなパケット構造体:
| 分野 | タイプ | エンディアンネス | 注記 |
|---|---|---|---|
| id | uint8 | n/a | パケットの一意の識別子 |
| CompressionAlgorithm | uint8 | 圧縮アルゴリズム[NONE、OPENSSL、ZLIB、GZIP、SNAPPY、何でも] | |
| ストリーム | バッファ[] | パケットストリームの配列(ストリームアレイ内の各要素は、エンコードされた/およびcompressionAlgorithmでデコードされるパケットバッファーを表します) |
その後、有効なデータグラムカプセル/sバッファーに送信します
非ラクネットパケットを送信するには、まず、カプセルバッファーサイズがMTUサイズをマイナス2に加えて3、4倍(データグラムのデータヘッダーバイトの長さの場合)よりも大きいかどうかを比較して、セグメンテーションが必要かどうかを判断し、セキュリティが使用されている場合は11を減算します。次に、指定された値をカプセルサイズで減算します。セグメンテーションが必要な場合は、カプセルのストリームをデータグラムのキューに追加する前に、カプセルのストリームを除去します。セグメンテーションが不要な場合は、キューに直接追加します。セグメント化されたパケットが信頼できないことを忘れないでください。 if they are, convert them to reliable packets to guarantee successful and ordered delivery of all packet parts.
The way to segment it into parts:
get the capsule size and also the capsule buffer size then the size that you used to check if is greater than the capsule buffer size and define them.
to get the count of how many segments is needed to be made: subtract the capsule buffer size with 1 then divide it with the size that you used to check if is greater than the capsule buffer size then sum them with 1 (not two times) or you can ceil instead of subtracting 1 and adding 1 at the end
then define a current segment index outside the loop and is 0 by default
then do a loop that will use the count of how many segments then the segmentation process will start:
after that define a variable representing start offset and it is equals to current segment index multiplied by the size that you used to check if is greater than the capsule buffer size
after that define a variable representing bytes to send that is equals to capsule buffer size subtracted by start offset
check if bytes to send is greater than the size that you used to check if is greater than the capsule buffer size and if true set the bytes to send value to the size that you used to check...
after that create a new variable representing the end offset
check if the bytes to send is not the size that you used to check if is greater than the capsule buffer size then set the end offset to the capsule buffer size subtracted by the current segment index multiplied by the size that you used to check if is greater than the capsule buffer size
if the check fails then the end offset will be the bytes to send
after that slice the capsule buffer with the start offset and end offset then you can do the feilds in the capsule.
you will need an array that has the capsules that contains the segments that will then be sent in queue.
the segment id will be the sender last segment id property that will increment outside the loop every time.
Here are a list of resources to help you better understand the RakNet protocol: