【问题标题】:what is the use of "cc" here , buffer[i].ToString("x2") != "cc"这里的“cc”有什么用,buffer[i].ToString("x2") != "cc"
【发布时间】:2021-07-20 13:24:51
【问题描述】:
byte[] buffer = null;
            
while (true)
{
    int bytesRead = 0;

    try
    {
        buffer = new byte[BUFFER_SIZE];
        bytesRead = clientse.stream.Read(buffer, 0, BUFFER_SIZE);
    }
    catch
    {      
        break;
    }

    int ReadLength = 0;
    for (int i = 0; i < BUFFER_SIZE; i++)
    {
        if (buffer[i].ToString("x2") != "cc")
        {
            ReadLength++;
        }
        else
            break;
    }
}

在这里,如果我将“cc”的值更改为其他值,它不会给我正确的读取长度计数。有人能详细说明一下代码中“cc”的用法吗?

【问题讨论】:

  • 似乎正在接收的数据具有任意字节值(十六进制的 0xCC 或十进制的 204)来终止消息。当然,这 100% 取决于实现。奇怪的是bytesRead 没有被使用。
  • 是从 C++ 代码移植过来的吗?对于调试版本,一些系统用 0xCC 填充新分配的数组,看起来这段代码试图使用它来查看填充了多少缓冲区。(1)那是糟糕的代码,(2)如果数据实际上包括一个 0xCC,(3)它只适用于调试版本,(4)它根本不适用于 C#。解决方案是使用 bytesRead 而不是尝试找到第一个未更改的字节(这对于 C# 根本不起作用,并且对于 C++ 充其量是可疑的)
  • 当然,发送代码可能正在发送一个带有 0xCC 的缓冲区以指示数据结束(可能是因为我在上一条消息中概述的原因)。
  • 这样检查效率很低,最好只做buffer[i] != 0xCC

标签: c# string format byte buffer


【解决方案1】:

正如我与@canton7 讨论的那样,0xCC 可能不用作流终止符,而是用作数据包分隔符。这个循环几乎没用,但考虑到您之后很可能有更多可能使用 ReadLength 的代码,您应该替换

    int ReadLength = 0;
    for (int i = 0; i < BUFFER_SIZE; i++)
    {
        if (buffer[i].ToString("x2") != "cc")
        {
            ReadLength++;
        }
        else
            break;
    }

int ReadLength = bytesRead - 1;

【讨论】:

  • 我认为这有点误导——OP的代码处理字节数组,没有迹象表明涉及字符,所以谈论文本如何编码为ASCII字节,然后显示为十六进制字符, 有点无关紧要。更中肯的一点是,代码是在测试buffer[i] == 0xcc,还是204。
  • 你是对的!我在答案的末尾添加了解释。谢谢!
  • 我认为您的额外解释没有帮助——没有足够的信息来说明是否可以删除循环。 bytesRead 只给你接收到的数据量,而不是每个单独数据包的长度——如果你背靠背读取两个数据包怎么办?据推测,数据包不能包含0xcc 作为其字节之一,并且协议是围绕它设计的,但是在没有任何协议知识的情况下,我们真的不能说太多。
  • 我不同意你关于协议带宽的看法 - 请注意程序如何通过缓冲区的单个 bytes - 缓冲区是一个字节 [] 所以缓冲区 [i]是一个字节。对于缓冲区的每个字节,我们将 ReadLength 变量加 1。 Stream.Read 告诉您它从源读取的字节数,因此这两个变量相等。
  • 没有。 Stream 只是一个字节流:它不引入任何。人们通常希望发送数据包——具有开始和结束的离散消息。为此,您在数据包周围放置某种框架,然后将它们连续写入Stream。当您从Stream 读取数据时,您只会得到一些字节,其中可能包含半个数据包、1 个数据包或 1.5 个数据包等。我的猜测是 OP 的代码正试图将这个字节流转回不同的数据包,通过寻找标记一个数据包结束和下一个数据包开始的
猜你喜欢
  • 1970-01-01
  • 2020-05-25
  • 2016-01-15
  • 2017-01-08
  • 2011-02-27
  • 2014-01-12
  • 1970-01-01
  • 2016-01-18
  • 1970-01-01
相关资源
最近更新 更多