On Mon Sep 11 21:41:23 2023 +0000, Zebediah Figura wrote:
Sorry, I think I was failing to think through things properly. Let me start over, and try to understand the problem. So the observation is that Windows *will* drop packets that overflow the buffer size, but internally the buffer size is capped to some minimum value regardless of the value of SO_RCVBUF? And we know that said minimum value is the same as the initial value of SO_RCVBUF, at least on 8+? If I understand this all correctly: should we be trying to clamp our internal SO_RCVBUF to that value on Windows, instead of whatever the initial value of Unix SO_RCVBUF happens to be?
We also had some chat with Zeb to discuss this. To summarize: - saying that Windows (or Linux) is dropping packets in case of TCP is not quite correct, it depends on what server as doing which is retransmitting the packet essentially blocking further send; - the other question raised was whether _RCVBUF does anything at all on Windows (e. g., shouldn't we just always set it to 64k);
I designed an ad-hoc test which tries to measure the effect of Windows rcvbuf in the following way: - the receiving part (Windows) sets SO_RCVBUF being tested and waits for 2sec after accept before calling receive; - sending part (Linux_ tries to send as much data as possible during ~300ms calling async send; - then receiving part wakes and receives everything, prints how much data actually received.
So testing like that confirms that setting values below 64k (up to date Windows default reported RCVBUF) doesn't seem to change anything, while increasing the value above does increase amount of data recevied this way. 64k is probably not random, it is about maximum UDP packet size and TCP fragment size.
So I think bottom line of this is: - avoiding setting short _RCVBUF still makes sense; - minding Unix system default probably doesn't, we can better just use 64k minimum; - we still need to set _RCVBUF for bigger values, it affects thing (in somewhat similar way on Windows and Unix).
I've sent an updated patch.