データのコマンドパケットをバイト配列として送信するクライアント/サーバーアーキテクチャ(C#.Net 4.0)があります。任意のコマンドには可変数のパラメータがあり、各パラメータは可変長です。このため、私はパラメータの終わりとコマンド全体の区切り文字を使用します。オペランドは常に2バイトで、両方のタイプの区切り文字は1バイトです。 command_delmiterは同じ機能を提供するため、最後のparameter_delmiterは冗長です。TCP/IPクライアント/サーバーコマンドデータ
コマンド構造は以下の通りです:
FIELD SIZE(BYTES)
operand 2
parameter1 x
parameter_delmiter 1
parameter2 x
parameter_delmiter 1
parameterN x
.............
.............
command_delmiter 1
パラメータはすなわち、int型、文字列などは、すべてのバイト配列にエンコード、多くの異なる種類から供給されています。
問題は、バイト配列にエンコードされたときにパラメータがデリミタと同じ値のバイトを含むことがあることです。例えば、command_delmiter = 255 ..とすると、パラメタの中にそのバイトがあるかもしれません。
私はこれを固定と考えることができ、3つの方法があります:
1)彼らは区切り文字(255と254)モジュラスと同じ値になることはありませんように、異なるパラメータをエンコード?。これは、パラメタが大きくなる、つまりInt16が2バイト以上になることを意味します。
2)区切り文字をまったく使用しないで、コマンド構造体の先頭にcountとlengthの値を使用します。
3)他のものを使用してください。私の知る限りでは、TCP/IPは、仕事をバッファリング方法は、区切り文字の何らかのを区切るために使用する必要があります「コマンド」やバッファなどのデータの束は、「複数のコマンドを含むことができ、またはAという
ですコマンドは複数のバッファにまたがる可能性があります。だからこそ
BinaryReader/Writerは明らかな候補のようですが、バイト配列に複数のコマンド(パラメータを含む)が含まれている可能性があります。したがって、BinaryReaderを理解するためには、バイト配列を細分化する必要があります。
提案?
ありがとうございました。
ええ私はすでに、すべての着信データを追加する別々の「蓄積」バッファーを保持しています。私はこの二次バッファを有効で完全なデータ「チャンク(chunk)」にチェックして、それらを再処理する。したがって、デリミタの代わりに長さを使用することをお勧めします。私が正しい道があると思ったことを確認していただきありがとうございます。 –