OSSP CVS Repository

ossp - Check-in [1230]
Not logged in
[Honeypot]  [Browse]  [Home]  [Login]  [Reports
[Search]  [Ticket]  [Timeline
  [Patchset]  [Tagging/Branching

Check-in Number: 1230
Date: 2001-Oct-31 14:11:25 (local)
2001-Oct-31 13:11:25 (UTC)
User:rse
Branch:
Comment: remember the issue now that we did our best
Tickets:
Inspections:
Files:
ossp-pkg/sa/TODO      1.28 -> 1.29     18 inserted, 12 deleted

ossp-pkg/sa/TODO 1.28 -> 1.29

--- 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),

CVSTrac 2.0.1