我对应该通过 Unix 上的 C 中的套接字写入/读取的字节数有一些疑问。我习惯于发送 1024 个字节，但有时当我发送短字符串时这真的太多了。
我从文件中读取了一个字符串，我不知道这个字符串有多少字节，它每次都可以变化，可以是 10、20 或 1000。我只知道它 < 1024。所以，当我编写代码，我不知道在客户端读取的字节大小，（在我可以使用的服务器上strlen()）。那么，无论我从文件中读取的字符串的长度如何，始终读取最大字节数（在这种情况下为 1024）的唯一解决方案是什么？
例如，使用此代码：
read(socket,stringBuff,SIZE);
SIZE如果我想读取一个 10 字节的字符串，如果是 10 而不是 1024 不是更好吗？
在您问题的代码中，如果只有 10 个字节要读取，那么无论SIZE是 10 个字节、1,024 个字节还是 1,000,024 个字节都没有区别——它仍然只会读取 10 个字节。唯一的区别是你为它预留了多少内存，如果你可以接收一个最多 1,024 字节的字符串，那么无论如何你都必须预留那么多内存。
但是，无论您尝试读取多少字节，您始终必须为read()实际读取不同数量的字节的可能性做好准备。特别是在网络上，当您在传输中遇到延迟时，即使您的服务器发送的是 1,024 字节的字符串，但在您的客户端调用时到达的字节数可能少于该数量read()，在这种情况下，您将读取少于 1,024 .
因此，您始终必须为在多个read()电话中获得您的意见的需要做好准备。这意味着您需要能够判断何时完成阅读输入 - 您不能仅依靠read()返回的事实来告诉您已完成。如果您的服务器可能在您阅读第一条消息之前发送了不止一条消息，那么您显然不能指望依赖于此。
您有三个主要选择：
始终发送大小相同的消息，如有必要，可能会用零填充较小的字符串。这对于 TCP 流来说通常是次优的。只需阅读，直到您完全收到这个字节数。
有某种哨兵机制来告诉您消息何时结束。这可能是换行符、a CRLF、空行或一行中的单个点后跟一个空行，或者任何适用于您的协议的内容。继续阅读，直到你收到这个哨兵。为了避免一次对一个字符进行低效的系统调用，您需要实现某种缓冲机制以使其正常工作。如果您可以确定您的服务器正在向您发送以单个'\n'字符结尾的行，那么使用fdopen()标准 CI/O 库可能是一种选择。
让您的服务器告诉您消息有多大（在初始固定长度字段中，或使用第 2 点中的相同类型的哨兵机制），然后继续阅读，直到获得该字节数。