1

背景: 私はさまざまなデバイス インターフェイスを扱ってきましたが、データの整合性がアプリケーション プロトコル レベルで処理される多くのシリアルおよび UDP など、多くのプロトコルを見てきました。私は、一般的なプロトコルの受信ルーチン処理を改善しようとしており、プロトコルの「理想的な」設計を検討しています。

私の質問は次のとおりです。すべての場合に破損したデータを明確に識別できるプロトコル フレーミング スキームはありますか? たとえば、多くのプロトコルの標準的なフレーミング スキームを考えてみましょう。

Field: Length in bytes
<SOH>: 1
<other framing information>: arbitrary, but fixed for a given protocol
<length>: 1 or 2
<data payload etc.>: based on length field (above)
<checksum/CRC>: 1 or 2
<ETX>: 1

ほとんどの場合、これで問題なく動作します。データを受信すると、SOH (または開始バイト シーケンスが何であれ) を検索し、固定バイト数を長さフィールドに移動し、そのバイト数 (プラスまたはマイナスの固定オフセット) を長さフィールドに移動します。パケットの末尾を CRC に送信し、それがチェックアウトされた場合、有効なパケットがあることがわかります。SOH を検索したり、長さフィールドに基づいて CRC を取得したりするのに十分なバイト数が入力バッファーにない場合は、CRC をチェックするのに十分なバイト数を受け取るまで待ちます。CRC 衝突を無視すると (それについてできることはあまりありません)、これにより、パケットが適切に形成され、破損していないことが保証されます。

ただし、長さフィールド自体が破損していて、値が高い場合 (私が実行している)、破損した長さを満たすのに十分なバイト数で入力バッファーをいっぱいにするまで、(破損した) パケットの CRC を確認することはできません。フィールドの要件。

では、受信ハンドラーまたはプロトコル設計自体のいずれかで、これを回避する決定論的な方法はありますか? 最大パケット長またはタイムアウトを設定して、受信ハンドラーで受信バッファーをフラッシュすることができます。これにより、実用的なレベルで問題を解決できるはずですが、一般的なケースで機能する「純粋な」理論的解決策があるかどうかはまだ疑問です実装固有の最大長やタイムアウトを設定する必要はありません。

ありがとう！

4

2 に答える 2

3

「ストリーミング」データを処理するものを含む、私が知っているすべてのプロトコルが、それぞれ独自のチェックを搭載した小さな伝送単位でデータストリームを切り刻む理由は、まさにあなたが説明する問題を回避するためです。おそらく、プロトコル設計の根本的な欠陥は、ブロックが大きすぎることです。

このSOの質問の受け入れられた回答には、この主題に関する非常に興味深い（しかし数学に重きを置いた）論文への適切な説明とリンクが含まれています。

要するに、実際のプログラミング関連の引数のためだけでなく、crc によって提供されるセキュリティを決定する際のメッセージ長の役割のために、より小さな送信ユニットに固執する必要があります。

于 2012-06-29T15:57:17.673 に答える
1

1 つの方法は、長さパラメーターをエンコードして、破損していることを簡単に検出できるようにし、大きなバッファーを読み取って CRC をチェックする手間を省くことです。

たとえば、XModem プロトコルは、1 の補数が後に続く 8 ビットのパケット番号を埋め込みます。

長さのブロックサイズを2倍にすることを意味する可能性がありますが、それはオプションです。

于 2012-06-30T20:09:08.437 に答える