Write on full buffer
opened this issue · comments
From docs:
- Streams are essentially “always” writable. The only time they aren’t is when their respective write buffers are full.
If I understand correct: this code is used when buffer are NOT full and if buffers are full this code is used to schedule the writes, and this code are writing them
- How can I simulate such a situation ? I am really curious to test this behavior.
- What are the advantages to use such an implementation ? Why not just loop
fwrite()
You test this by writing large chunks of data to a stream, in particular > 128 KiB (depends on internal buffer sizes, but 128 KiB turned our to always be enough).
E.g. you create a socket pair and write > 128 KB onto it without reading from it.
The code in case there's no full buffer is about reducing latency. Otherwise we have to wait until the next tick for sending the data. You will in particular notice that on servers with a high load.
Thank you @bwoebi, I have done some tests, and get another question :)
example:
- client
fwrite()128 bytes of data to stream - server don't
fread()them
in this case client's fwrite() will succeed, and there are no way to detect if server fread() / stream_get_contents() them ?
P.S: I suppose that's why we always have server confirmations in classic client <-> server topology
Correct.
You still have to consider, even if you'd rely on a TCP confirmation, it still doesn't mean that a server actually processed something, it just means that the kernel (or if we move that to userspace: the application) has received it. But that doesn't contain any meaningful information for us: we want to know whether a client processed something. So, yes.
@bwoebi Thank you, this was very informative, I think we can close this.