2011-08-17 12 views
0

データのコマンドパケットをバイト配列として送信するクライアント/サーバーアーキテクチャ(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を理解するためには、バイト配列を細分化する必要があります。

提案?

ありがとうございました。

答えて

1

これを行う標準的な方法は、メッセージの長さをメッセージの(固定)最初の数バイトにすることです。したがって、メッセージの長さを示す最初の4バイトを持つことができ、メッセージの内容についてそれらの多くのバイトを読み取ることができます。次の4バイトは、次のメッセージの長さになります。長さ0は、メッセージの終わりを示すことができます。または、メッセージ数のヘッダーを使用することもできます。

また、TCPはバイトストリームなので、ソケットからデータを読み取るたびに完全なメッセージを利用できるとは限りません。これまで読んでいた任意のバイト数を受け取ることができました。

+0

ええ私はすでに、すべての着信データを追加する別々の「蓄積」バッファーを保持しています。私はこの二次バッファを有効で完全なデータ「チャンク(chunk)」にチェックして、それらを再処理する。したがって、デリミタの代わりに長さを使用することをお勧めします。私が正しい道があると思ったことを確認していただきありがとうございます。 –

関連する問題