Does anyone have any idea where this additional buffering is coming from?
I know just enough on this subject to be dangerous, so take what I say with a handful of salt.
As I understand it, with modern networks it is permissible for routers that transition from one medium to another (coax to fibre to wireless etc.), to coalesce packets for the same destination (as the MTU for the various media changes), in order to improve throughput. So, unless you control all the routers between the nodes, you cannot expect that destination of a stream will receive the data in the same sized chunks as you send them.
The only mechanism I'm aware of that might be usable to prevent this coalescing is QoS. Designed to reduce latency of high-priority packets, it might be possible to use it to achieve the affect you are after...but I do not think there are any guarantees. Basically, sockets are streams, not packet-oriented, and legacy apps that relied on earlier side-effects for their correct function should be re-written.
Caveat reader!
In reply to Re: Sockets, autoflush, and TCP_NODELAY
by BrowserUk
in thread Sockets, autoflush, and TCP_NODELAY
by packetwhacker
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |