TCP/IP 客户端/服务器命令数据
我有一个客户端/服务器架构（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.. 并且参数中可能包含该字节。
我可以考虑通过 3 种方法来解决此问题：
1）对参数进行不同的编码，以便它们永远不会与分隔符（255 和 254）模数？相同。这意味着参数将变得更大，即 Int16 将超过 2 个字节等。
2) 根本不使用分隔符，在命令结构的开头使用计数和长度值。
3）使用其他东西。
据我所知，TCP/IP 缓冲区的工作方式是必须使用某种定界符来分隔“命令”或“数据包”，因为缓冲区可能会包含多个命令，或者一个命令可能跨越多个缓冲区。所以这个
BinaryReader / Writer 似乎是一个明显的候选者，唯一的问题是字节数组可能包含多个命令（内部带有参数）。因此，字节数组仍然需要被切碎才能进入 BinaryReader。
建议？
谢谢。
I have a Client/Server architecture (C# .Net 4.0) that send's command packets of data as byte arrays. There is a variable number of parameters in any command, and each paramater is of variable length. Because of this I use delimiters for the end of a parameter and the command as a whole. The operand is always 2 bytes and both types of delimiter are 1 byte. The last parameter_delmiter is redundant as command_delmiter provides the same functionality.
The command structure is as follow:
FIELD SIZE(BYTES)
operand 2
parameter1 x
parameter_delmiter 1
parameter2 x
parameter_delmiter 1
parameterN x
.............
.............
command_delmiter 1
Parameters are sourced from many different types, ie, ints, strings etc all encoded into byte arrays.
The problem I have is that sometimes parameters when encoded into byte arrays contain bytes that are the same value as a delimiter. For example command_delmiter=255.. and a paramater may have that byte inside of it.
There is 3 ways I can think of fixing this:
1) Encode the parameters differently so that they can never be the same value as a delimiter (255 and 254) Modulus?. This will mean that paramaters will become larger, ie Int16 will be more than 2 bytes etc.
2) Do not use delimiters at all, use count and length values at the start of the command structure.
3) Use something else.
To my knowledge, the way TCP/IP buffers work is that SOME SORT of delimiter has to be used to seperate 'commands' or 'bundles of data' as a buffer may contain multiple commands, or a command may span multiple buffers.. So this
BinaryReader / Writer seems like an obvious candidate, the only issue is that the byte array may contain multiple commands ( with parameters inside). So the byte array would still have to be chopped up in order to feel into the BinaryReader.
Suggestions?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
执行此操作的标准方法是将消息的长度放在消息的（固定）前几个字节中。因此，您可以使用前 4 个字节来表示消息的长度，然后读取这些字节来获取消息的内容。接下来的 4 个字节将是下一条消息的长度。长度为 0 可能表示消息结束。或者您可以使用带有消息计数的标头。
另外，请记住 TCP 是字节流，因此不要期望每次从套接字读取数据时都能获得完整的消息。您可以在读取时接收任意数量的字节。
The standard way to do this is to have the length of the message in the (fixed) first few bytes of a message. So you could have the first 4 bytes to denote the length of a message, read those many bytes for the content of the message. The next 4 bytes would be the length of the next message. A length of 0 could indicate end of messages. Or you could use a header with a message count.
Also, remember TCP is a byte stream, so don't expect a complete message to be available every time you read data from a socket. You could receive an arbitrary number of bytes at ever read.