How to disable buffering in fread ()?

Question

I read and write to sockets using fread () and fwrite (). These functions, I believe, are intended to buffer input and output. Is there a way to disable buffering when using these features?

Edit:

I am creating a remote desktop application and the remote client seems to be “a little behind the server” and I don’t know what the reason is ... I thought it might be due to read and write buffering .. but using setvbuf doesn’t worked.

By "lagging" I mean that the remote desktop client is running for a few seconds behind the server. What the server does at a certain moment is reflected on the client side after a delay of about 15-20 seconds.

Also, I don't want to-use-fread () because it is part of existing code. I do not want to change it. In the end, I could use write () and read (), but I would like to avoid this.

Answer 1

You can use setvbuf to disable buffering for a specific file pointer:

 setvbuf(fp, NULL, _IONBF, 0); 

EDIT

Mixing sockets with standard input is quite complicated, as Stevens warns. Here are a few quotes.

The problem with these three three functions [fseek, fsetpos, rewing] is that they all call lseek, which does not work on the socket.

The easiest way to deal with this read-write problem is to open two standard input / output streams for this socket: one for reading and one for writing .

One way to fix this [buffering] problem is to force the output stream to buffer strings by calling setvbuf. The other is to force each echo line to be printed by calling fflush after each call to fputs. But in practice, any of these solutions are still error prone and may not interact well with the Nagle algorithm.

---

Finally:

Try stopping using stdio . It makes no sense to use stdio and fread and fwrite . Instead, use direct read and write . Stevens says failure because people use fgets and fputs with stdio

Answer 2

Using

 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. 

defined in stdio.h

Answer 3

By "lagging" I mean that the remote desktop client is running for a few seconds behind the server. What the server does at a certain moment is reflected on the client side after a delay of about 15-20 seconds.

You need to 100% confirm two things.

1) Is the client fread in fread ? If not, then it lags behind because it is too busy to keep up with the server (or the code is broken and foolishly doesn't call fread ). In any case, buffering and the network are not to blame.

2) Did the client receive fewer bytes from completed calls to fread than the server sent its completed calls to fwrite ? If not, then he is “behind” because he misunderstood some of the data he received (he did not understand that he received some data that he received). In this case, buffering and the network are not to blame.

I bet from 10 to 1 that one of the two things that I talked about above is a case.

To clarify two cases, if this is not clear, consider the following example:

1) The server sends a message.

2) The server sends a message.

3) The client calls fread and receives both messages, but due to broken code, only thinks that he received it. (Perhaps a broken code suggests that messages cannot "stick together.")

4) At this stage, it may seem that the client is “behind” the message, but in fact the client code is simply broken. The client read as many bytes as the server sent. He is not far behind, just broke.

Until you exclude these two types of “busy code” and “broken code,” you should not assume that the network is to blame, as this is the least likely explanation.