UDPメッセージをあるデバイスから別のデバイスに送信しています。メッセージ内にタイムスタンプがあり、16ビットフィールドで送信されます。受信機は、フィールドが「ロールオーバ」する回数を追跡し、16ビットを超える時間スパンを追跡できるようにします。プロトコル設計者は、32ビットタイムスタンプ全体を使用してメッセージのCRCを計算する必要があると判断しました。これは良いアイデアですか？メッセージ期間は「ロールオーバー」期間よりもはるかに短いことに注意してください。CRCを計算するためのメッセージに暗黙のデータを使用していますか良い設計戦略ですか？
明らかにメッセージを管理しているので、メッセージに32ビットのタイムスタンプを送信するだけです。
CRCのサイズはどれくらいですか？ 16ビットCRCの場合、エラー検出機能を完全に忘れて、方程式を解いて、送信メッセージとCRCからタイムスタンプの欠落した16ビットを得ることができます。しかし、もしあなたがそれをやろうとしたら、CRCの代わりにCRCフィールドに直接タイムスタンプの他の16ビットを送るだけではいかがですか？
32ビットCRCの場合は、32ビットではなく、エラー検出で16ビットの「強度」を残して解決できます。もう一度、他の16ビットのタイムスタンプを送信し、残っているものに16ビットのCRCを入れてください。
メッセージの長さを変更できる場合は、欠落している16ビットのタイムスタンプを追加して、CRCとそのエラー検出機能をそのままにしてください。
これは24ビットCRCです。プロトコル設計者は、システムが追加の障害モード、すなわちロールオーバの計算におけるエラーを検出すると考えていたと思う。私が見る問題は、ロールオーバー計算のエラーの場合に通信が麻痺するということです。単純な比較でロールオーバーを確認するのは、UDPパケットが順不同で到着したときに失敗するので、設計上の欠陥だと思います。しかし、私は人々の考えを聞きたい。 – Gerry
良いデザインではありません。アプリケーションロジック（タイマーのオーバーフロー）でデータ伝送レイヤー（ペイロードの整合性）が不正に悪化します。 - CRCチェックが失敗したらどうしますか？ペイロードが壊れていたか（ - >再試行/無視）、タイマーが離れていましたか？言いたくない。 - ペイロードの一部として完全なタイムスタンプを明示的に送信しないのはなぜですか？ – JimmyB