Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 8761 invoked by uid 6000); 22 Oct 1999 20:41:26 -0000 Received: (qmail 8656 invoked from network); 22 Oct 1999 20:41:22 -0000 Received: from twinlark.arctic.org (204.107.140.52) by taz.hyperreal.org with SMTP; 22 Oct 1999 20:41:22 -0000 Received: (qmail 11900 invoked by uid 500); 22 Oct 1999 20:41:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Oct 1999 20:41:14 -0000 Date: Fri, 22 Oct 1999 13:41:14 -0700 (PDT) From: Dean Gaudet To: Apache Developers Mailing List Subject: Re: local/remote address in conn_rec In-Reply-To: <199910201334.XAA17484@silk.apana.org.au> Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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