On Fri Sep 1 21:24:40 2023 +0000, Zebediah Figura wrote:
Oh, I actually misread this test... now that I can properly tell which calls are SNDBUF and which are RCVBUF, I'm confused. Partly as to why we're bothering to test the default value of RCVBUF in the first place, but also: if the point is to test that small values of RCVBUF don't result in dropping packets, don't those test results contradict that assertion? Or are the applications depending on this simply broken on Windows < 8? One additional thing that bothers me about this, now that I look—one thing that *also* changed between 7 and 8 is that TCP loopback got some sort of fast path that results in its packets always being synchronous. I wonder if "packets are never dropped despite RCVBUF" is actually just a consequence of loopback, and is not actually true if packets come over the network.
I am not bothering to test default value, but having it big enough for 3 buffers is a prerequisite for the test to be able to test what it is testing. Of course I could use a smaller buffer probably, but I don't see what that will change as probably (in the view of the default buffer size is not specified anywhere and may be configured on Linux, even though such small default values don't make sense and are likely to break things for apps anyway) it should still be checked?
Yes, the point is that small values of RCVBUF do not result in dropping packets (*at least* until they fit into the default buffer size). I am afraid I am not quite following, which is the assertion and how that contradicts? I am not testing default buffer, I am testing what happens when a small buffer size is set (while to make the test work predictably default buffer should be big enough). Application(s) under concern are those which set buffer size to some small value (or 0 like in the present case). They still won't get broken before Win8 in this aspect as soon as they call async receive (because network packets will fit in 8192 buffer; while Linux is taking this small buffer size more seriously and starts dropping packets).
I am attaching the (very ad-hoc) manual test on top of this patch which I used to testing it over real network. To use it, hardcoded server_ip in the top of tcp_socketpair_flags should be set, then 'ws2_32_test.exe sock' run on the server side and after that 'ws2_32_test.exe sock send' on the client side. I think the test show that over real network nothing is lost as well.
[test.patch](/uploads/103764283ca0246cbfae3efaf5d5912c/test.patch)