cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h

[Nate Lawson]

On Fri, 9 Jan 2004, Andre Oppermann wrote:
> Nate Lawson wrote:
> > Perhaps you didn't understand Mike?  You don't care if TCP_NODELAY is set
> > on their side, all you care about is the packet equilibrium.  If you send
> > data in response to receiving a segment, the net equilibrium is preserved.
> > The real behavior you want to detect is someone sending a lot of small
> > chunks of data that the application could process as larger chunks.  If
> > the application waits until it has a full "record" before responding, you
> > can distinguish the degenerate case by the application's response rate.
>
> Ok, that is a very useful distinction.  I could modify the detection
> logic to take *sent* packets into account (except ACKs of course).

Yes, that is what he was saying.  You want to account for write()s to the
socket and not packets since retransmits or other packet layer stuff
should not decrement the counter.

> At least Oracle seems to set it on the server side too.  That is how
> I came to my conclusion.  Methinks something like fsync() for tcp
> sockets might be useful.  If the database is doing a write for every
> row it has got from the query result with TCP_NODELAY it is quite
> inefficient.  On the other hand if there is only one row you don't
> want to Nagle-delay the answer.  With a tcp fsync() the database
> could simply do its write as before and the socket buffer will queue
> it until a max MSS packet is filled.  When the last row is written it
> will issue a fsync() and whatever is in the buffer will get sent out
> immediatly.  This would make the database communication way more effective
> because the database client usually is not processing the answers until
> the full query result is received.  Even then, we don't get any delay
> just fully used packets.
>
> Taking this further also telnet and SSH could benefit from this.  When
> ^C a large listing or so takes ages to take effect because there are
> so many small packets in flight.  So when there is bulk data it again
> can have both worlds large packets and fast answers/responses.
>
> What do you think?  (I know this is off-topic to the minmss settings)

Sounds ok although I'm not the best person to ask.  Check for POSIX or
some other standards on this one.

-Nate