you're completely and utterly wrong.

1. And besides, PUSH is to do with whether to return from a blocking read after the first packet, or to wait for further packets;
No, it indicates whether a receiving TCP should deliver the data to the application (at the same time ACKing to the remote side), or wait for the 200ms delayed ACK interval, in the hope of receiving more data. It has ABSOLUTELY nothing to do with blocking or non-blocking reads.

no client stack in the world will return *part* of the data from its input buffer just because one packet had the PUSH flag set. PUSH is not a TCP record boundary; there is no such thing.
If the PSH flag is set, it WILL be delivered to the application.

It does not matter what the receiving stack's buffer size is. I know it doesn't on Windows, and I suspect at least on BSD-derived implementations it's the same.

Have you actually tried your theory out ? Try receiving a file from the empeg in 16k chunks instead of 1024 like the current emptool seems to.


If you are only receiving one packet per read call on Windows, it's because you're calling read more often than the wire rate of the packets.
That's wrong again. you're telling me that the wire rate is at the most 579k/sec on a 10MB ?

I don't have a linux machine to investigate this behaviour myself. but I will try openbsd and see what it does.

In any case, if you're sure it's not caused by TCP_NODELAY then there's not much you can do. So I guess i'll have to live with it.