Index: ossp-pkg/sa/TODO
RCS File: /v/ossp/cvs/ossp-pkg/sa/TODO,v
rcsdiff -q -kk '-r1.28' '-r1.29' -u '/v/ossp/cvs/ossp-pkg/sa/TODO,v' 2>/dev/null
--- TODO	2001/10/31 09:46:06	1.28
+++ TODO	2001/10/31 13:11:25	1.29
@@ -2,18 +2,6 @@
 TODO
 ----
 
-Oh, finally, a performance issue (that probably doesn't matter for
-lmtp2nntp):
-sa_rc_t sa_read(sa_t *sa, char *cpBuf, size_t nBufReq, size_t *nBufRes)
-always flushes the write portion of the outgoing stream, even if the
-read is going to be entirely from the local buffer.  This is generally
-undesirably behavior, since you can trigger nagle's algorithm if
-you're a command/response server with pipelining like LMTP.
-Generally, you want to flush the write portion whenever you're about
-to block on a read, but not necessarily before.
-(Of course, the client-side of a pipelining client is considerably
-more complex.)
-
 - on resolving multiple addresses can be returned (especially
   one IPv4 and one IPv6!) and each one has to be tried on
   socket+connect for instance. What to do? See also
@@ -26,6 +14,24 @@
 CANDO
 -----
 
+o Nagle's Algorithm and Flushing of Output Buffers.
+   
+  The kernel performs Nagle's Algorithm (see RFC 896 and search for "nagle
+  algorithm" on www.whatis.com [currently
+  http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html]
+  on his internal output buffers. Although we flush our user-space output
+  buffers only if we really perform a read(2) (and not if the read is going to
+  be served entirely from the local buffer) this does not mean that really
+  every character the remote has already sent is also already read by us.
+  Because the kernel also has a read buffer. Optimal behaviour would be that
+  we flush out output buffer only if the read(2) would block. OTOH flushing
+  out buffers means performing a write(2) and this again is buffered in the
+  kernel, too. So performing an optimal read->write->read->write->... sequence
+  is very complex and non-trivial to implement. Especially because even using
+  Nagle's Algorithm always is not the right choice (see
+  http://www.w3.org/Protocols/HTTP/Performance/Nagle/ for details), especially
+  when it comes to pipelining protocols.
+
 o Support for writev(2).
 
   This can be done by internally switching to always use writev(2),