TCP / IP客户端/服务器命令数据

时间:2011-08-17 09:17:40

标签: parsing tcp command bytearray

我有一个客户端/服务器架构(C#.Net 4.0),它将命令数据包作为字节数组发送。在任何命令中都有可变数量的参数,并且每个参数具有可变长度。因此,我使用分隔符作为参数的结尾和整个命令。操作数总是2个字节,两种类型的分隔符都是1个字节。最后一个parameter_delmiter是冗余的,因为command_delmiter提供了相同的功能。

命令结构如下:

FIELD                  SIZE(BYTES)
operand                2
parameter1             x
parameter_delmiter     1
parameter2             x
parameter_delmiter     1
parameterN             x
.............
.............
command_delmiter       1

参数来自许多不同的类型,即整数,字符串等都编码为字节数组。

我遇到的问题是,有时编码到字节数组中的参数包含与分隔符值相同的字节。例如,command_delmiter = 255 ..并且参数可以在其中包含该字节。

有三种方法可以解决这个问题:

1)对参数进行不同的编码,使它们永远不会与分隔符(255和254)模数相同。这意味着参数将变大,即Int16将超过2个字节等。

2)根本不要使用分隔符,在命令结构的开头使用count和length值。

3)使用别的东西。

据我所知,TCP / IP缓冲区的工作方式是 SOME SORT 的分隔符必须用于分隔“命令”或“数据包”缓冲区可能包含多个命令,或者命令可能跨越多个缓冲区。所以这个

BinaryReader / Writer似乎是一个明显的候选者,唯一的问题是字节数​​组可能包含多个命令(里面有参数)。所以字节数组仍然必须被切断才能感觉到BinaryReader。

建议?

感谢。

1 个答案:

答案 0 :(得分:1)

执行此操作的标准方法是将消息的长度放在消息的(固定)前几个字节中。因此,您可以使用前4个字节来表示消息的长度,为消息内容读取那么多字节。接下来的4个字节将是下一个消息的长度。长度为0可能表示消息结束。或者您可以使用带有消息计数的标题。

另外,请记住TCP是一个字节流,因此每次从套接字读取数据时都不要期望有完整的消息可用。您可以在读取时收到任意数量的字节。