How many bytes should I read/write to a socket?
我对在 Unix 上通过 C 中的套接字写入/读取的字节数有些疑问。我习惯发送 1024 字节,但有时当我发送短字符串时,这真的太多了。
我从一个文件中读取一个字符串,我不知道这个字符串是多少字节,它每次都可以变化,可以是10、20或1000。我只知道它是< 1024。所以,当我编写代码时,我不知道在客户端读取的字节大小,(在服务器上我可以使用 strlen())。那么,无论我从文件中读取的字符串的长度如何,是始终读取最大字节数(在这种情况下为 1024)的唯一解决方案吗?
例如,使用以下代码:
1
| read(socket,stringBuff,SIZE); |
如果我想读取一个 10 字节的字符串,如果 SIZE 是 10 而不是 1024 会更好吗?
- recv() 返回通过套接字接收的字节数。
-
请不要使用一个问题来宣传不同的问题。
-
@timrau 是的,我知道,也读过,但如果我没记错的话,当你写一个读调用时,你应该写一些类似 read(socket,stringBuff,SIZE) 的东西,并在 SIZE 中指定你想要的字符数读书。我的意思是,如果我读取一个 10 字符的字符串,如果 SIZE 是 10 而不是 1024 会更好吗?
-
为您使用的任何协议的标头读取足够的字节,然后从该标头中计算出预期的长度,然后读取那么多字节
在您问题的代码中,如果只有 10 个字节要读取,那么 SIZE 是 10 个字节、1,024 个字节还是 1,000,024 个字节都没有区别 - 它仍然只会读取 10 个字节。唯一的区别是您为其预留了多少内存,如果您可以接收最多 1,024 字节的字符串,那么无论如何您都必须预留那么多内存。
但是,无论您尝试读入多少字节,您始终必须为 read() 实际读取不同数量的字节的可能性做好准备。特别是在网络上,当您在传输中遇到延迟时,即使您的服务器正在发送一个 1,024 字节的字符串,在您的客户端调用 read() 时到达的字节数也可能少于该字节数,在这种情况下,您将阅读小于 1,024。
因此,您必须随时准备好在多个 read() 调用中获取您的输入。这意味着您需要能够判断何时完成读取输入 - 您不能仅依靠 read() 已返回来告诉您您已完成的事实。如果您的服务器在您阅读第一条消息之前可能会发送多条消息,那么您显然不能指望依靠这一点。
您有三个主要选择:
始终发送相同大小的消息,必要时可能用零填充较小的字符串。这对于 TCP 流来说通常不是最理想的。只需阅读,直到您收到确切的字节数。
有某种哨兵机制来告诉你消息何时结束。这可能是换行符、CRLF、空行或一行上的一个点,后跟一个空行,或者任何适用于您的协议的内容。继续阅读,直到您收到此哨兵。为了避免一次对一个字符进行低效的系统调用,您需要实现某种缓冲机制以使其正常工作。如果您可以确定您的服务器正在向您发送以单个 '\
' 字符结尾的行,那么使用 fdopen() 和标准 C I/O 库可能是一种选择。
让您的服务器告诉您消息有多大(在初始固定长度字段中,或使用与第 2 点相同的哨兵机制),然后继续阅读,直到您获得该字节数。
read() 系统调用阻塞,直到它可以读取一个或多个字节,或者直到发生错误。
它不保证它会读取您请求的字节数!使用 TCP 套接字时,read() 返回的值通常少于您的请求,这是很常见的,因为它无法返回仍在通过网络传播的字节。
所以,如果你没有得到你想要的一切,你将不得不检查 read() 的返回值并再次调用它以获取更多数据,一次又一次,直到你拥有一切。