httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: local/remote address in conn_rec
Date Fri, 22 Oct 1999 20:41:14 GMT


On Wed, 20 Oct 1999, Brian Havard wrote:

> Hi all,
>   After gettings 2.0 to build and run on OS/2 I noticed that the access log
> is showing rubbish for the client address. I traced the problem back to the
> fact that the client & server address records (sa_client, sa_server) passed
> to ap_new_connection() are never set.
> 
>   The question is, should we still be using sockaddr_in structures with APR?
> I would think no, which would mean the conn_rec's
> 
>     struct sockaddr_in local_addr;	/* local address */
>     struct sockaddr_in remote_addr;	/* remote address */
> 
> will need to change, but to what? Perhaps two ap_socket_t *'s ? That would
> allow things like ap_getipaddr() & ap_get_remote_hostname() to be used on
> them.

btw, making this two ap_socket_t's would be absolutely wrong.

the berkeley socket API has very few warts, few that apache ever
encounters.  you should be striving to implement it in a portable way, not
invent a new API.

> One other thing I noticed. When using ap_accept() in the main loop the new
> sockets created are allocated from the global pool (same pool as the listen
> socket was allocated from) which means it will never be freed, leaking one
> ap_socket_t for every connection. The only way I can see around this is to
> give ap_accept a context to allocate new sockets from instead of using the
> listener's context.

this was never a problem before, because the main loop was responsible for
registering the cleanup for the sockets... moving it to APR requires
changing the main loop to create the connection pool before it calls
accept.

Dean


Mime
View raw message