Keeping track of socket settings...

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

[This is from a discussion on new-httpd]

dean posted as follows..

the {get,set}sockopt stuff is TCP_NODELAY and CORK.  those aren't terribly
expensive system calls at all... but it's still tempting to clean them up.
i'd say that since all sockopt calls go through APR it can keep track
of the current state -- it could even defer setting TCP_NODELAY until
a naked write comes along (i.e. a write which isn't part of a sendfile
sequence which uses CORK).

btw, the sendfile code for linux does a bunch of "if (corked)" tests --
conditionals like that can slow stuff down especially since the most
common usage is going to be one sendfile per response, and it'll always
have headers and always be corked.  it doesn't hurt to always cork.

F_GETFL followed by F_SETFL -- i'm not aware of any case where we have
to do the F_GETFL.  we know we want O_RDWR|O_NONBLOCK and can set it
directly.  worst case scenario is that we can figure something like this
out at config time (or maybe have a hint or whatever so that on linux,
solaris and probably freebsd we just set O_RDWR|O_NONBLOCK directly).

i haven't looked into what's causing the read/EAGAIN -- the response
here had "Connection: close", and there should be no need to read before
going into lingering close.

Some of this is apr specific, so ...

It seems like a good idea to keep track of what we have set as the socket
options.  Should we simply use a variable (apr_int32_t umask for example)
and check the bits?  Would this work across all platforms?  Bill?  Brian?

david

Re: Keeping track of socket settings...

[dean gaudet <de...@arctic.org>]

On Sun, 7 Jan 2001, David Reid wrote:

> Greg,
>
> Nicely put and that's exactly what I had in mind but after spending 10 hours
> flogging to St Pete & back my mind isn't working as well as normal! (Mind
> due, does it ever??)  Of course I was going to use the TCP_ flags but the
> APR should do the job...  That said, we don't currently allow the user to
> set TCP_CORK or TCP_NOPUSH, so maybe we should think about that?  Tracking
> the TCP_ options might be safer and more flexible?

i think there may be cases where CORK/NOPUSH could be useful at layers
above APR.

an example might be WebMUX and sendfile() combined.  if this is even
possible i haven't thought it through.

MUX protocols are really desirable from a performance point of view, but a
total pain in the ass to figure out all the nitty gritty details of when
you write() and what you put in the write()s.

last time i hurt myself thinking about this i think i came up with a clean
solution using CORK, and then proceeded to curse the traditional BSD
socket API because.  i'll post again if i figure it out.

-dean

Re: Keeping track of socket settings...

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

Greg,

Nicely put and that's exactly what I had in mind but after spending 10 hours
flogging to St Pete & back my mind isn't working as well as normal! (Mind
due, does it ever??)  Of course I was going to use the TCP_ flags but the
APR should do the job...  That said, we don't currently allow the user to
set TCP_CORK or TCP_NOPUSH, so maybe we should think about that?  Tracking
the TCP_ options might be safer and more flexible?

david

[apologies to Greg for sending him this twice, but I forgot about the reply
all again until I'd sent it!!!]

> > Some of this is apr specific, so ...
> >
> > It seems like a good idea to keep track of what we have set as the
socket
> > options.  Should we simply use a variable (apr_int32_t umask for
example)
> > and check the bits?  Would this work across all platforms?  Bill?
Brian?
>
> It should definitely work across all platforms. When you stop and realize
> that APR has a portable setsockopt() interface, then we simply track
*those*
> flags. We don't have to track what's happening at the platform-specific
> level.
>
> You've got 10 flags listed in apr_network_io.h. Just keep those flags in
the
> socket structure in an "int" somewhere (no need to get complicated with an
> apr_int32_t).
>
> When an apr_setsockopt() actually changes one of the flags, then you
reflect
> that down into the platform-specific socket.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

Re: Keeping track of socket settings...

[Greg Stein <gs...@lyra.org>]

On Sun, Jan 07, 2001 at 08:47:14PM -0000, David Reid wrote:
> [This is from a discussion on new-httpd]
> 
> dean posted as follows..
>----start----
> 
> the {get,set}sockopt stuff is TCP_NODELAY and CORK.  those aren't terribly
> expensive system calls at all... but it's still tempting to clean them up.
> i'd say that since all sockopt calls go through APR it can keep track
> of the current state -- it could even defer setting TCP_NODELAY until
> a naked write comes along (i.e. a write which isn't part of a sendfile
> sequence which uses CORK).
> 
> btw, the sendfile code for linux does a bunch of "if (corked)" tests --
> conditionals like that can slow stuff down especially since the most
> common usage is going to be one sendfile per response, and it'll always
> have headers and always be corked.  it doesn't hurt to always cork.
> 
> F_GETFL followed by F_SETFL -- i'm not aware of any case where we have
> to do the F_GETFL.  we know we want O_RDWR|O_NONBLOCK and can set it
> directly.  worst case scenario is that we can figure something like this
> out at config time (or maybe have a hint or whatever so that on linux,
> solaris and probably freebsd we just set O_RDWR|O_NONBLOCK directly).
> 
> i haven't looked into what's causing the read/EAGAIN -- the response
> here had "Connection: close", and there should be no need to read before
> going into lingering close.
>----end----
> 
> Some of this is apr specific, so ...
> 
> It seems like a good idea to keep track of what we have set as the socket
> options.  Should we simply use a variable (apr_int32_t umask for example)
> and check the bits?  Would this work across all platforms?  Bill?  Brian?

It should definitely work across all platforms. When you stop and realize
that APR has a portable setsockopt() interface, then we simply track *those*
flags. We don't have to track what's happening at the platform-specific
level.

You've got 10 flags listed in apr_network_io.h. Just keep those flags in the
socket structure in an "int" somewhere (no need to get complicated with an
apr_int32_t).

When an apr_setsockopt() actually changes one of the flags, then you reflect
that down into the platform-specific socket.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/