communication - バイトプロトコルの構築に関するヒント

Question

デバイス間でデータを通信していますが、プロトコルをバイト配列としてプログラムする必要があります。

低レベルでプロトコルを構築する際のヒントはありますか? ..例：

score 2 · Accepted Answer

これは、基盤となるトランスポート層のQoS（Quality Of Service）特性に依存します。

基盤となるチャネルが信頼できる場合、CRCはおそらくやり過ぎです（何らかの形式の整合性チェックが下位のプロトコル層で行われると仮定します）。

バイトストリームからペイロードを描画する方法について質問している場合は、いくつかの可能性があります。そのうちの1つは、ストリームをBASE64でエンコード/デコードすることだけです。繰り返しになりますが、要件によっては、BASE64がオーバーヘッドを大きくしすぎる可能性があります。

もちろん、ペイロードで発生する可能性が低いHEADER（一意のシーケンス+ペイロード長+ CRC）をいつでも使用できますが、HEADERなどが重複する可能性を最小限に抑えるために、ペイロードにスクランブラーを適用する必要があります。

信頼性の低いバイトストリーム指向のプロコトールのプロトコルを構築しようとしているのなら、なぜ車輪の再発明をするのでしょうか。PPPのようなものを使ってみませんか？

score 1 · Accepted Answer

チェックサムについては、基になるプロトコルに依存します。ただし、自分で実装することはできます。Encrypt、Hash、Crunch、Flip、2s メッセージを補完し、結果を 1 つのチェックバイトに格納します

score 0 · Accepted Answer

人間が読めるプロトコルを使用できるかどうかを慎重に
検討してから、生のbianryではなく圧縮を使用できるかどうかを検討してください

score 0 · Accepted Answer

重要な部分は、下位層で提供されるものに依存します。以下に、私が重要と考える理由を説明する例を示します。

ITU H.223 プロトコルの実装に参加したことがあります。最悪だったのは、データストリームがバイトまたはビットストリームベースである可能性があり、下位層では生のビット以外に何も提供されませんでした。プロトコルには、トランスポートの信頼性と上位層の機能要件に応じて、いくつかの可能な層がありました。
もう 1 つの例は、TCP を介した ITU H.225 プロトコルで、トランスポートは信頼できるものでしたが、バイトストリームでした。したがって、適切なメッセージ区切りロジックが実装されている必要があります。
さて、UDPベースのSIPです。データグラム。非常に便利。しかし、メッセージングの信頼性に関連する多くの問題がありました。そのため、シーケンスとリクエスト/レスポンスの追跡 (トランザクション、レグなど) は非常に重要でした。
OK、何らかの理由で RPC プロトコルを使用しました。あなたが怠け者なら良いことです。アプリケーションロジックに関連するいくつかの制限がありますが、学ぶためだけでもこれを見ることをお勧めします.
NASA IPC は、私が少し前に見たものでした。良い、上層に関連する非常にシンプル。しかし、制限とは集中化されたものです。

もう1つの重要なポイントは次のとおりです。最初にニーズを見てプロトコルを設計する必要があります（上位層の要件を分析します）。本当にこれを行う必要がある場合、CRC-32は分析よりもデータの整合性を保護するための最良の方法であるという知識で何を与えますか(例として)?

ええと、これらの言及は、少し異なる視点で主題について考えるのに役立つかもしれないと思います.

communication - バイト プロトコルの構築に関するヒント