5

According to this Socket FAQ article, Nagle's algorithm is one of many algorithms that can cause a bunch of data to sit in the TCP buffer and not hit the wire. The delay from the Nagle algorithm can be up to 200ms.

For some reason, Nagle's algorithm can be turned off completely, but not flushed just once. This is really puzzling to me. Why is there no way to say that "just this one time, don't wait for any more data. Just act as if Nagle's 200ms are up."

Wouldn't that make perfect sense, and strike a good balance between no Nagle at all, Nagle all the time, and implementing one's own protocol from scratch?

Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • Nagle's algorithm does not delay your first `send()`. And it only delays your second `send()` if the acknowledgement of the first `send()` has not arrived yet. So one way of avoiding the delay imposed by Nagle's algorithm is to merge as many send() operations as possible into one. – hagello Aug 19 '15 at 22:08

2 Answers2

1

Good question. I guess nobody ever really needed it or they got around it. If I remember correctly, enabling TCP_NODELAY pushes the data immediately. Then you can just disable it.

Of course, this comes at the high cost of two system calls for a "flush". What you could do: send(2), on Unix implementations has a flags argument. You could implement your own flag, something like: MSG_JUSTPUSHIT (okay, maybe another name) and consider it in tcp_output.

cnicutar
  • 178,505
  • 25
  • 365
  • 392
1

In performance-sensitive applications where the delays introduced by Nagle's algorithm are an issue, it's often easier to just disable Nagle's algorithm entirely and emulate its batching in software by using scatter/gather IO (e.g, writev(), or by implementing buffering in software where needed). As an added bonus, doing this cuts out some system call overhead.

Alternatively, you can open up two separate sockets and disable Nagling on one of them. Just keep in mind that data sent on one socket won't necessarily be synced up with the other one.

  • I have an application which sends lots of data unidirectionally but also communicates interactively every few seconds. This means that neither always-on nor always-off works well enough. It seems that the Nagle flush would be the easiest way to solve this. – Roman Starkov Jul 17 '11 at 21:48
  • Added another idea to the post above (two sockets). –  Jul 17 '11 at 21:52
  • Unfortunately the two processes need to be synchronized. – Roman Starkov Jul 17 '11 at 22:17