apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: OK...
Date Thu, 16 Nov 2000 20:22:22 GMT
> > > > This would then give
> > > >     apr_sockaddr_t *sa;
> > > >     apr_gethostbyname(&sa, "hostname", pool);
> > > >     apr_connect(sock, sa);
> > >
> > > We need to add more arguments: address family for sure and possibly
> > > flags.  Look at getaddrinfo().  And do we want to add an optional
> > > service name/port number parameter?  That would build the complete
> > > sockaddr for us.
> >
> > OK.  Care to suggest the definition?
>
> apr_status_t apr_getaddrinfo(apr_sockaddr_t *sa,
>                              const char *hostname,
>                              apr_int32_t family,
>                              apr_port_t port,
>                              apr_pool_t *p);
>
> hostname is one of three things:
> a) ptr to DNS name
> b) ptr to numeric address string
> c) NULL if we don't have a name/address and just want to build a
>    sockaddr with address INADDR[6]_ANY and some port.

+1 for this and your subsequent patch.

Just a thought, should we define the socket families as APR values?  This
would mean that on a non-v6 platform we could still call create socket with
APR_V6 as a family and we'd just return an error.  Don't know if it makes
sense or not...

Also, do we want to be able to pass in a servicename for the port?
Otherwise I think we should add a function to get the numeric port for a
service name...

>
> family is AF_UNSPEC if we don't care, AF_INET or AF_INET6 otherwise.
> You can't have hostname == NULL and family == AF_UNSPEC.
>
> port will be stored into the new sockaddr; pass zero if you don't
> care.
>
> There is no flags parameter for now, but we may need to allow that
> eventually.

If we think we'll need it should we add it now so we don't break the API
when we do?

>
> > > In addition to the changes you mentioned, I see apr_create_socket() as
> > > extremely important in the short run and I think we should think about
> > > apr_bind() working like apr_connect() (in other words, taking an
> > > apr_sockaddr_t).  That makes sense when the user has told us the local
> > > interface address and we have to resolve it anyway.  We have to keep
> > > it from being painful when we just have the port number.
> >
> > OK, so again care to suggest the API definitions?
>
> I think apr_connect() is good the way it is.
>
> For apr_bind(), I see it looking like apr_connect():
>
>   apr_status_t apr_bind(apr_socket_t *, apr_sockaddr_t *);
>
> Why?

This makes sense.

+1

>
>   This allows an app to use apr_getaddrinfo(), which will allocate a
>   socket address, store the port in the right place, and perhaps
>   handle a local interface address specified by the user.

david


Mime
View raw message