On Fri Sep 1 22:16:03 2023 +0000, Paul Gofman wrote:
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)
As for my original test in the patch, I think it shows that without my changes setting short receive buffer length breaks things *even* on a loopback interface and makes no sense (even though the ultimate details may be different on real network interface).