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

[Mike Silbersack]

On Fri, 9 Jan 2004, Andre Oppermann 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).

Yep, Nate read me correctly.

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

I think that you're describing linux's TCP_CORK option.  I think that we
have similar behavior right now with some socket option, but not exactly
the same... it might not be a bad idea to just try to be explicitly
compatible.

Mike "Silby" Silbersack