httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <>
Subject Re: [PATCH] apr_sockaddr_t & friends
Date Tue, 14 Nov 2000 13:25:45 GMT

No worries.  I'd just like to get this lot committed so I can return to a
form of sanity (if that's possible) :)

> . I hope we can simplify the set of functions which manipulate some
>   form of the address before we commit it.
>   o apr_get_name() doesn't seem to be needed (as you suggest in a
>     comment); zap it
>   o apr_socket_inet_pton() is used only inside an APR routine; zap it
>     and call inet_pton() directly; we need to ship inet_pton() and
>     inet_ntop() for internal APR use so that we're thread-safe and we
>     simplify our code a bit
>   o Look at this set of routines:
>     apr_get_inaddr() - looks up a hostname?
>     apr_get_socket_inaddr() - return local or remote apr_in_addr_t?
>     apr_get_v4_address() - return IPv4 address from apr_in_addr_t?
>     apr_inaddr_compare()
>     apr_inet_ntop() - return numeric address string from apr_in_addr_t?
>     apr_gethostbyname() - do lookup on local or remote address
>     apr_socket_inet_pton() - parse hostname?
>     apr_socket_inet_ntop()
>     apr_get_hostname() - do gethostbyaddr() on one of the sockaddrs
>       for a socket
>     I'd rather see the apr_sockaddr_t as the one standard object apps
>     use when dealing with the addresses.  Basing operations on this
>     will make UDP support more natural, because with UDP socket
>     addresses and hostnames have to be independent of the socket since
>     multiple peers are used with a given socket.  We won't want to
>     limit ourselves to operations that use the single remote sockaddr
>     in the apr_socket_t.
>     very rough sketch:
>     apr_get_address() can give us one of the apr_sockaddr_t objects on
>     a socket
>       apr_get_address(&local, APR_LOCAL, p);
>       apr_get_address(&remote, APR_REMOTE, p);

OK. p is an apr_socket_t I'm guessing?  If so then I'm +1 for this and will
add it...

>     apr_get_nas() can give us the numeric address string for an
>     apr_sockaddr_t
>       apr_get_nas(&nas, local);
>       This will call inet_ntop() on the IP address within the local
>       apr_sockaddr_t, store the string in the apr_sockaddr_t in case
>       we're called again, and return the address of the string.

OK.  I can go for this as well :)

>     apr_getnameinfo() can do a reverse DNS lookup on the IP address in
>     an apr_sockaddr_t

OK.  This makes sense.

>       apr_getnameinfo(&dnsname, remote)
>     apr_getaddrinfo() can do a DNS lookup on the hostname in an
>     apr_sockaddr_t, filling in the ipaddr field in the apr_sockaddr_t

Yep, this makes sense as well.

However, if we have an apr_socket_t with the remote/local apr-sockaddr_t's
aren't we duplicating a lot of stuff?  I guess there's some step that I'm
missing here...

> Recommended first steps IMHO:
> . ship inet_ntop() and inet_pton() for internal APR use; stop using
>   inet_ntoa() and inet_aton() (at least inside APR)

OK.  I guess FreeBSD's will do?  Can I just grab them or what?

> . look at some of these starts at standardizing/simplifying the API

Yeah well...


View raw message