On 28/07/2020 15:04, Michael McMahon wrote:
The code is technically racy on the GET test, but it's often the case
when you want
something to be racy then it turns out not to be in practice, 99 times
out of a 100 anyway
(figures made up). I was thinking you could put a random sleep on the
client
On 27/07/2020 17:24, Daniel Fuchs wrote:
Hi Michael,
On 24/07/2020 16:38, Michael McMahon wrote:
Daniel,
That's all fine. Concerning the test, I think the approach looks good,
but I wonder if instead of just synchronizing on the CFs to make
the cancel happen at the same time always, would it
Hi Alan,
Thanks again for testing this change. I dug deep into the issue yesterday and
got some answers from the Windows Networking team.
The issue is that the flag TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS, which we
passed in to completely eliminate the network delay, isn't defined (or checked)
