如何在 fread() 中禁用缓冲？

Question

我正在使用 fread() 和 fwrite() 读写套接字。我相信这些功能用于缓冲输入和输出。有什么方法可以让我在使用这些功能的同时禁用缓冲？

编辑：

我正在构建一个远程桌面应用程序，远程客户端似乎“落后于服务器”，我不知道可能是什么原因......我认为这可能是因为缓冲读取和写..但使用 setvbuf 不起作用。

“滞后”是指远程桌面客户端在服务器之后运行几秒钟。服务器在特定时刻所做的事情会在大约 15-20 秒的延迟后反映在客户端上。

另外，我不想不使用-fread()，因为它是现有代码的一部分。我不想修改它。我最终可以使用 write() 和 read()，但我想避免它。

Answer 1

您可以使用setvbuf 禁用特定文件指针的缓冲：

setvbuf(fp, NULL, _IONBF, 0);

编辑

正如 Stevens 所警告的那样，将套接字与标准输入混合使用有点棘手。以下是一些引述。

后三个函数 [fseek, fsetpos, rewing] 的问题在于 他们都调用 lseek，这在套接字上失败了。

处理这个读写问题最简单的方法是打开两个 给定套接字的标准 I/O 流：一个用于读取，一个用于 写作。

解决这个[缓冲问题]的一种方法是强制输出流 通过调用 setvbuf 进行行缓冲。另一个是强制每个 在每次调用 fputs 后调用 fflush 来回显要输出的行。 但在实践中，这些解决方案中的任何一个仍然容易出错，并且 可能与 Nagle 算法交互不良

---

总结：

尝试停止使用stdio。 使用stdio 和fread 和fwrite 是没有意义的。请直接使用read 和write。 Stevens 谈到“行缓冲”输出，因为人们使用 fgets 和 fputs 与 stdio

Answer 2

使用

int setvbuf ( FILE * stream, char * buffer, int mode, size_t size );

mode
    Specifies a mode for file buffering:
    _IOFBF  Full buffering: On output, data is written once the buffer is full. On Input the buffer is filled when an input operation is requested and the buffer is empty.
    _IOLBF  Line buffering: On output, data is written when a newline character is inserted into the stream or when the buffer is full, whatever happens first. On Input, the buffer is filled up to the next newline character when an input operation is requested and the buffer is empty.
    _IONBF  No buffering: No buffer is used. Each I/O operation is written as soon as possible. In this case, the buffer and size parameters are ignored.

在stdio.h中定义

Answer 3

“滞后”是指远程桌面客户端在服务器之后运行几秒钟。服务器在特定时刻所做的事情会在大约 15-20 秒的延迟后反映在客户端上。

你需要 100% 确认两件事。

1) 客户端是否在fread 中被阻止？如果没有，那么它就会滞后，因为它太忙而无法跟上服务器的速度（或者代码被破坏并且愚蠢地没有调用fread）。无论哪种情况，缓冲和网络都没有问题。

2) 客户端从其对fread 的已完成调用中收到的总字节数是否少于服务器在其已完成对fwrite 的调用中发送的总字节数？如果不是，那么它就是“滞后”的，因为它误解了它收到的一些数据（没有意识到它得到了一些它实际得到的数据）。在这种情况下，缓冲和网络没有问题。

我会以 10 比 1 的赔率与您打赌，我上面提到的两件事之一就是这种情况。

为了在不清楚的情况下澄清第二种情况，请考虑以下示例：

1) 服务器发送消息。

2) 服务器发送消息。

3) 客户端调用fread 并收到两条消息，但由于代码损坏，只认为它已收到一条消息。 （也许损坏的代码假定消息不能“粘在一起”。）

4) 此时，可能看起来客户端被消息“滞后”了，但实际上，客户端的代码只是被破坏了。客户端读取的字节数与服务器发送的字节数一样多。它没有滞后，只是坏了。

在排除这两种“忙码”和“断码”类型的情况之前，您不应假设网络有问题，因为这是最不可能的解释。