Using Tcp, why are large data blocks transmitted with lower bandwidth and then with small data blocks?

Question

Using 2 Windows XP PCs, 64K Tcp window size associated with cross cable
Using Qt 4.5.3, QTcpServer and QTcpSocket

Sending 2000 messages at 40 KB takes 2 seconds (40 MB / s)
Sending 1 message 80 MB takes 80 seconds (1 MB / s)

Does anyone have an explanation? I would expect a larger message to go faster, since lower layers can then populate Tcp packets more efficiently.

Answer 1

Error in Qt 4.5.3

..................................

Answer 2

It's hard to comment without seeing your code.

How do you rate this on the sending side? When do you know you're done?

How does the client read the data, does it read in fixed-size buffers and discards the data, or does it somehow know (from framing) that the "message" is 80 MB, and try to create a "message" in one data buffer for transmission to the application level?

This is unlikely to be the main Windows socket code, which does not work well.

Edit: I wonder why the voices? It's a little more useful to leave a comment when you vote to say why, therefore, we can all learn.

Answer 3

TCP, on the application side, is flow-based, which means there are no packets, but just a sequence of bytes. The kernel can collect several records in the connection before sending it, and the receiving party can make any amount of received data available for each “read” call.

TCP, on the IP side, is a packet. Since standard Ethernet has an MTU (maximum transmission unit) of 1,500 bytes, and both TCP and IP have 20 byte headers, each packet transmitted over Ethernet will transmit 1,460 bytes (or less) of the TCP stream to the other side. 40KB or 80MB of entries from the application here will not make any difference.

How long it takes data to transmit depends on how and where you measure it. A 40 KB record is likely to return immediately after this amount of data is simply deleted in the TCP “send” window in the kernel. Recording to 80 MB will be blocked, waiting until all this is transferred (well, everything except the last 64 KB, which will correspond to the expectation in the window).

TCP baud rate also depends on the recipient. It has a “receive window” that contains everything received from a peer but not received by the application. The amount of space available in this window is transferred to the sender with each ACK return, so if it is not quickly freed up by the receiving application, the sender will eventually stop. WireShark can give some information here.

In the end, both methods must be carried over in the same period of time, because the application can easily fill the outgoing window faster than TCP can send it no matter how this data is broken.

I can not talk about the work of QT.