2

2 つのアプリケーションが TCP/IP ストリームを介して通信するためのプロトコルを作成しており、メッセージのヘッダーを設計する方法を考えています。最初のガイドとして TCP ヘッダーを使用すると、パディングが必要かどうか疑問に思います。キャッシュを扱うときは、保存されているデータがキャッシュの行に収まるようにして、取得時に効率的に処理できるようにしたいことを理解しています。ただし、アプリケーションがバイトのストリームを解析し、適切と思われる方法で保存することを考慮して、ヘッダーをパディングすることがどのように理にかなっているのか理解できません。

例: 3 バイトのフィールドと、それに続く 1 バイトのパディング フィールドで構成されるメッセージ ヘッダーを 32 ビット アラインメント用に送信したいと考えています。次に、メッセージ データを送信します。

この場合、受信側はストリームから 3 バイトを取得し、パディング バイトを破棄します。そして、メッセージ データの読み取りを開始します。私が見たところ、彼は 3 バイトとメッセージ データを希望どおりに保存していません。バイトアライメントの要点は、効率的に取得できるようにすることです。しかし、レトリバーがパディングを気にしない場合、どうすれば効率的に取得できるのでしょうか?

パディングがない場合、リトリーバーはストリームから 3 ヘッダー バイトを取得し、次にデータ バイトを取得します。レトリバーはこれらのバイトを好きなように保存するので、パディングが行われるかどうかはどのように問題になるのでしょうか?

多分私はパディングのポイントを逃しています。

この投稿から質問を抽出するのは少し難しいですが、私が言ったことで、皆さんはおそらく私の誤解を指摘することができます.

皆さんの考えを教えてください。

ありがとう、ジブ

4

5 に答える 5

2

メッセージ本文の単語の配置が役立つ場合は、必ず、他のゆがみを避けるためにメッセージを埋めてください。メッセージの大部分が適切な強度の機械語として処理される場合、パディングは有益です。

メッセージが xml などのバイトのストリームである場合、パディングはまったく役に立ちません。

ワイヤ プロトコルを実際に設計する限り、(ヘッダーを含めて) 圧縮されたプレーン テキスト プロトコルを使用することを検討する必要があります。これは、手動で設計したバイナリ プロトコルよりも使用する帯域幅が少なくなる可能性があります。

于 2009-06-17T01:31:01.037 に答える
2

アプリケーションがバイトのストリームを解析し、適切と思われる方法で保存することを考慮して、ヘッダーをパディングすることがどのように理にかなっているのか理解できません。

もし私が受信側なら、バッファ (すなわちバイトの配列) をプロトコル ドライバ (つまり TCP スタック) に渡し、「データが入ったらこれを返してください」と言うかもしれません。

私 (アプリケーション) が返すのは、データを含むバイト配列です。「キャスト」などのCスタイルのトリックを使用して、この配列の一部を単語やダブルワード（バイトだけでなく）であるかのように扱うことができます...それらが適切に整列されている場合（パディングがある可能性があります）必要）。

バイト バッファーのオフセットから DWORD を読み取るステートメントの例を次に示します。

DWORD getDword(const byte* buffer)
{
  //we want the DWORD which starts at byte-offset 8
  buffer += 8;
  //dereference as if it were pointing to a DWORD
  //(this would fail on some machines if the pointer
  //weren't pointing to a DWORD-aligned boundary)
  return *((DWORD*)buffer);
}

Intel アセンブリの対応する関数は次のとおりです。これは単一のオペコードであることに注意してください。つまり、データにアクセスするための非常に効率的な方法であり、個別のバイトを読み取って蓄積するよりも効率的です。

mov eax,DWORD PTR [esi+8]
于 2009-06-17T01:50:47.253 に答える
1

3 バイトのヘッダーがあり、それを 4 バイトに揃える場合は、未使用のバイトを「将来の使用のために予約済み」として指定し、ビットをゼロにする必要があります (形式が正しくないメッセージを拒否します)。これにより、ある程度の拡張性が残ります。または、バイトをバージョン番号として使用することもできます。最初は 0 で、プロトコルに互換性のない変更を加えた場合 (いつ) は増分します。値を「未定義」や「気にしない」にしないでください。その方法で開始すると、決して使用できなくなります。

于 2009-06-17T02:57:57.460 に答える
1

パディングを検討する理由の 1 つは、時間の経過とともにプロトコルを拡張する予定がある場合です。パディングの一部は、将来の割り当てのために意図的に取っておくことができます。

パディングを検討するもう 1 つの理由は、長さフィールドで数ビットを節約することです。つまり、常に 4 の倍数または 8 は、長さフィールドから 2 または 3 ビットを節約します。

于 2009-06-17T02:25:14.547 に答える
1

TCP にパディングがあるもう 1 つの正当な理由 (これはおそらくあなたには当てはまりません) は、専用のネットワーク処理ハードウェアがヘッダーからデータを簡単に分離できるようにすることです。データは常に 32 ビット境界で始まるため、パケットがルーティングされるときにデータからヘッダーを分離する方が簡単です。

于 2009-06-17T02:27:05.680 に答える