Weird send () problem (with Wireshark log)
I had another question on this issue, but I didn't ask properly, so here I am again!
I am posting the file by posting it in chunks. Right now, I am playing with different numbers for the size of this piece to see which size is most effective.
When tested on localhost, the size of any chunk works fine. But when I tested it over the net, it seems that the maximum block size is 8191 bytes. If I try any of the above, the transmission becomes extremely, painful, slow.
To show what's going on, here are the first 100 lines of Wireshark logs when I use a block size of 8191 bytes and when I use a block size of 8192 bytes: (sender is 192.168.0.102 and receiver is 192.168.0.100)
8191: http://pastebin.com/E7jFFY4p
8192: http://pastebin.com/9P2rYa1p
Note that in log 8192 on line 33, the receiver takes a long time to activate data. This happens again on line 103 and line 132. I believe this delay is the root of the problem.
Please note that I have not changed the SO_SNDBUF parameter or the TCP_NODELAY parameter.
So my question is , why am I getting delayed ACKs when sending files in 8192 byte chunks when everything works fine when using 8191 byte chunks?
a source to share
I understood that! I first did it myself and then after some additional digging found this: http://support.microsoft.com/kb/823764
What actually happens is that the send buffer allocated by Winsock is by default (on my machine) exactly 8192 bytes, when I put that number of bytes in the buffer (actually filling it completely), the next send () will provide WSAEWOULDBLOCK ... Then I would only get the next FD_WRITE when the bytes were ACKed.
But at the same time, the receiving machine did not send an ACK due to the delayed ACK algorithm. This stalled the transmission for 200ms, after which the receiving machine finally activates the data, which then allows the send function to receive the FD_WRITE.
Of course, none of this happens when I used 8191 bytes, because I did not fill the entire buffer, and thus the next send () did not block. This meant that Winsock would always send data in such a way that the deferred ACK algorithm was never kicked on the receiving end (except for the last packet if it was an odd-numbered packet).
Hope this helps someone else with the same problem as me.
a source to share