[PATCH] docs: Recommend TCP_NODELAY (disabling Nagle)
This text from https://en.wikipedia.org/wiki/Nagle%27s_algorithm
is telling:
"In any request-response application protocols where request data can
be larger than a packet, this can artificially impose a few hundred
milliseconds latency between the requester and the responder, even if
the requester has properly buffered the request data. Nagle's
algorithm should be disabled by the requester in this case. If the
response data can be larger than a packet, the responder should also
disable Nagle's algorithm so the requester can promptly receive the
whole response."
And we hit it in real life with libnbd/nbdkit - more than an order of
magnitude in slowdown results when trying to saturate a connection
with as many parallel requests as possible when Nagle's algorithm
introduces artificial delay waiting for the ACKs:
https://www.redhat.com/archives/libguestfs/2019-May/msg00237.html
Signed-off-by: Eric Blake <eblake@redhat.com>
---
doc/proto.md | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/proto.md b/doc/proto.md
index 918e4ea..37156c9 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -64,6 +64,17 @@ client to communicate the options to the kernel which were negotiated
with the server during the handshake. This document does not describe
those.
+When handling the client-side transmission phase with the Linux
+kernel, the socket between the client and server can use either Unix
+or TCP sockets. For other implementations, the client and server can
+use any agreeable communication channel (a socket is typical, but it
+is also possible to implement the NBD protocol over a pair of
+uni-directional pipes). If TCP sockets are used, both the client and
+server SHOULD disable Nagle's algorithm (that is, use `setsockopt` to
+set the `TCP_NODELAY` option to non-zero), to eliminate artificial
+delays waiting for ACK response that would otherwise arise when a
+large message payload spans multiple network packets.
+
### Handshake
The handshake is the first phase of the protocol. Its main purpose is to
--
2.20.1
Reply to: