APR_TCP_NOPUSH

[rb...@apache.org]

This concept is not portable at all as far as I know, so why do we expose
it in our API?  My understanding of TCP_NOPUSH is that it is how linux
implements sendfile.  If that is the case, then it should be removed from
our public API, and we should just use it behind the scenes.

If that isn't the case, then can somebody please explain how an
application that uses APR_TCP_NOPUSH is at all portable?  Once that flag
is used, the application will behave differently on many platforms.

I would like to remove that macro later this weekend, so please let me
know if that will be an issue.

Ryan

Re: APR_TCP_NOPUSH

["William A. Rowe, Jr." <wr...@apache.org>]

At 11:17 AM 12/13/2002, Aaron Bannert wrote:
>It looks to me like it's used in conjunction with sendfile
>on Linux, and is probably useful for preventing slow starts
>on big bursts of data (like a response). I suspect it is
>especially useful when each header in the hdtr->headers iovec
>is not going to fill a full packet. (Is this thing anything
>other than the opposite of TCP_NODELAY?)
>
>It is one of those things that only helps if you have it and
>doesn't hurt if you don't.

Huh?  What do you mean "it doesn't hurt"?  Badly coded network
code hurts like hell.  And exposing such a facility on some subset
of platforms means that the other platforms may thrash wildly in
response to bad code.

If we have to engineer around bad application code in APR, we have
to do so consistently.  That doesn't mean we can't support the concept
but that we have to implement it across the board... using _NOPUSH
if available and lots of set-aside code or another facility if not.

I would much rather see this implemented in terms of apr_ functions
and not yet-another-flag-to-setsockopt, so that we don't burden the
usual core network functions with this behavior.

Bill

Re: APR_TCP_NOPUSH

[Tony Finch <do...@dotat.at>]

On Mon, Dec 16, 2002 at 08:40:53AM -0800, rbb@apache.org wrote:
> 
> The point is that there are only two platforms that _can_ provide this
> behavior.  Windows, BeOS, netware, and OS/2 don't have this concept of
> holding back data and then allowing it to be sent.  In fact, only FreeBSD
> (and it's brethren) and Linux have it in the Unix world.

Of the BSDs, Only FreeBSD incorporated the T/TCP code.

Tony.
-- 
f.a.n.finch  <do...@dotat.at>  http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: EAST OR NORTHEAST 3 BECOMING SOUTHEAST
OR VARIABLE. FAIR, OR ISOLATED SHOWERS AT FIRST, LOCAL MISTS TUESDAY MORNING.
GOOD, OR POOR IN MISTS. SLIGHT.

Re: APR_TCP_NOPUSH

[Tony Finch <do...@dotat.at>]

On Mon, Dec 16, 2002 at 12:06:50PM -0000, David Reid wrote:
> 
> It was added as we originally had TCP_CORK and that is Linux only. We detect
> whether we have TCP_NOPUSH and try to make the usage as general as
> possible - that process should be fixed and improved on :)

TCP_NOPUSH is not the same as TCP_CORK -- it turns on a whole lot of
T/TCP features that you don't want if the server is anything other
than completely public-access.

Tony.
-- 
f.a.n.finch  <do...@dotat.at>  http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: EAST 2 OR 3
LOCALLY 4 GRADUALLY VEERING SOUTH TO SOUTHWEST 2 OR 3 LOCALLY 4. MOSTLY FAIR
WITH RISK OF OVERNIGHT MIST PATCHES. GENERALLY GOOD, BUT POOR IN MIST. SLIGHT.

Re: APR_TCP_NOPUSH

[rb...@apache.org]

On Mon, 16 Dec 2002, David Reid wrote:

> I'd rather see it documented and the issues looked at on the other
> platforms.
>
> It was added as we originally had TCP_CORK and that is Linux only. We detect
> whether we have TCP_NOPUSH and try to make the usage as general as
> possible - that process should be fixed and improved on :)

The point is that there are only two platforms that _can_ provide this
behavior.  Windows, BeOS, netware, and OS/2 don't have this concept of
holding back data and then allowing it to be sent.  In fact, only FreeBSD
(and it's brethren) and Linux have it in the Unix world.

That means that anybody who uses TCP_NOPUSH in APR isn't going to get the
behavior they expect.  They are going to get something very different.  We
take advantage of TCP_NOPUSH under the covers on platforms that have the
concept, so why are we exposing it????

Ryan

Re: APR_TCP_NOPUSH

[David Reid <dr...@jetnet.co.uk>]

I'd rather see it documented and the issues looked at on the other
platforms.

It was added as we originally had TCP_CORK and that is Linux only. We detect
whether we have TCP_NOPUSH and try to make the usage as general as
possible - that process should be fixed and improved on :)

david

----- Original Message -----
From: "Joe Orton" <jo...@manyfish.co.uk>
To: <de...@apr.apache.org>
Sent: Friday, December 13, 2002 8:07 PM
Subject: Re: APR_TCP_NOPUSH


> On Fri, Dec 13, 2002 at 10:12:17AM -0800, Ryan Bloom wrote:
> > So, I continue to wonder, how is it useful to have this in a _portable_
> > run-time, when the concept isn't at all portable?
>
> Will you also be removing threads, IPv6, and all the other stuff which
> isn't implemented on every single platforms APR supports?
>
> I don't care much about this particular issue, but I don't buy the
> argument: as Aaron said, setting TCP_CORK is a useful optimisation on
> platforms which support it. You can write a portable application which
> uses TCP_CORK if available and doesn't if it's not - just as you can
> write a portable app which can use threads.
>
> If you drop it from the APR API that just makes it considerably harder
> for people to use the optimisation: they would have write the autoconf
> checks, make their code a mess of ifdefs, call apr_os_sock_get to get
> the fd out, blah blah blah.  I'd wager the end result would be a less
> "portable" application than if the code was in APR, since it leaves more
> things for the app to screw up.
>
> Having said that, leaving NOPUSH in the API as undocumented as it is
> currently also allows the app to screw up and be unportable, so there's
> an argument for removing it.
>
> Regards,
>
> joe
>

Re: APR_TCP_NOPUSH

[rb...@apache.org]

On Fri, 13 Dec 2002, Joe Orton wrote:

> On Fri, Dec 13, 2002 at 10:12:17AM -0800, Ryan Bloom wrote:
> > So, I continue to wonder, how is it useful to have this in a _portable_
> > run-time, when the concept isn't at all portable?
>
> Will you also be removing threads, IPv6, and all the other stuff which
> isn't implemented on every single platforms APR supports?

Come on.   Those features are supported on most of the platforms we
support.  The one we are talking about is _UN_supported on most of the
platforms we support.  We have always had the concept of APR_ENOTIMPL, for
features that couldn't be implemented on a given platform.  But, that
reutrn code was meant to be the exception, not the rule.  In this case, we
have a feature that APR uses internally (and that nobody has asked for
externally), but that we have exposed to the outside world, even though it
is a completely non-portable concept.  Most platforms just can't do this.

Ryan

Re: APR_TCP_NOPUSH

[Joe Orton <jo...@manyfish.co.uk>]

On Fri, Dec 13, 2002 at 10:12:17AM -0800, Ryan Bloom wrote:
> So, I continue to wonder, how is it useful to have this in a _portable_
> run-time, when the concept isn't at all portable?

Will you also be removing threads, IPv6, and all the other stuff which
isn't implemented on every single platforms APR supports? 

I don't care much about this particular issue, but I don't buy the
argument: as Aaron said, setting TCP_CORK is a useful optimisation on
platforms which support it. You can write a portable application which
uses TCP_CORK if available and doesn't if it's not - just as you can
write a portable app which can use threads.

If you drop it from the APR API that just makes it considerably harder
for people to use the optimisation: they would have write the autoconf
checks, make their code a mess of ifdefs, call apr_os_sock_get to get
the fd out, blah blah blah.  I'd wager the end result would be a less
"portable" application than if the code was in APR, since it leaves more
things for the app to screw up.

Having said that, leaving NOPUSH in the API as undocumented as it is
currently also allows the app to screw up and be unportable, so there's
an argument for removing it.

Regards,

joe

Re: APR_TCP_NOPUSH

[rb...@apache.org]

On Fri, 13 Dec 2002, Aaron Bannert wrote:

> It looks to me like it's used in conjunction with sendfile
> on Linux, and is probably useful for preventing slow starts
> on big bursts of data (like a response). I suspect it is
> especially useful when each header in the hdtr->headers iovec
> is not going to fill a full packet. (Is this thing anything
> other than the opposite of TCP_NODELAY?)
>
> It is one of those things that only helps if you have it and
> doesn't hurt if you don't.

The web server doesn't use it to stop slow starts on big bursts of data,
because the concept is completely non-portable.  That makes the whole
thing ludicrous to have in a portable run-time.  If the app tries to take
advantage of APR_TCP_NODELAY, and they test on Linux or FreeBSD, it will
do exactly  what they expect.  However, if they test on _any_ other
platform, it won't.

So, I continue to wonder, how is it useful to have this in a _portable_
run-time, when the concept isn't at all portable?

Ryan

>
> -aaron
>
>
> On Friday, December 13, 2002, at 09:11  AM, <rb...@apache.org> wrote:
>
> >
> > This concept is not portable at all as far as I know, so why do we
> > expose
> > it in our API?  My understanding of TCP_NOPUSH is that it is how linux
> > implements sendfile.  If that is the case, then it should be removed
> > from
> > our public API, and we should just use it behind the scenes.
> >
> > If that isn't the case, then can somebody please explain how an
> > application that uses APR_TCP_NOPUSH is at all portable?  Once that
> > flag
> > is used, the application will behave differently on many platforms.
> >
> > I would like to remove that macro later this weekend, so please let me
> > know if that will be an issue.
>
>

Re: APR_TCP_NOPUSH

[Aaron Bannert <aa...@clove.org>]

It looks to me like it's used in conjunction with sendfile
on Linux, and is probably useful for preventing slow starts
on big bursts of data (like a response). I suspect it is
especially useful when each header in the hdtr->headers iovec
is not going to fill a full packet. (Is this thing anything
other than the opposite of TCP_NODELAY?)

It is one of those things that only helps if you have it and
doesn't hurt if you don't.

-aaron


On Friday, December 13, 2002, at 09:11  AM, <rb...@apache.org> wrote:

>
> This concept is not portable at all as far as I know, so why do we 
> expose
> it in our API?  My understanding of TCP_NOPUSH is that it is how linux
> implements sendfile.  If that is the case, then it should be removed 
> from
> our public API, and we should just use it behind the scenes.
>
> If that isn't the case, then can somebody please explain how an
> application that uses APR_TCP_NOPUSH is at all portable?  Once that 
> flag
> is used, the application will behave differently on many platforms.
>
> I would like to remove that macro later this weekend, so please let me
> know if that will be an issue.