Justin Erenkrantz wrote:
>
> On Fri, Jan 04, 2002 at 08:49:59PM -0500, Jeff Trawick wrote:
> > I'm pretty sure that native Win32 does not have AF_UNIX, but then what
> > would they need it for. You could argue that APR could have a common
> > API which on Unix might use AF_UNIX sockets and on Win32 might use
> > named pipes. I don't know what that API would be, though.
>
> Well, here is a use case for AF_UNIX sockets. Does anyone have a use
> case for named pipes on Win32? The code seemed close enough that it
> just made more sense to add the few bits here and there to try and
> get it to work. I just don't think in native Unix code anymore.
> I like coding with APR much better. =)
>
> > > This is needed for EGD support.
> >
> > not really... You don't need this to do AF_UNIX sockets inside APR.
> > A pure socket interface will avoid the pool issue too.
>
> Granted - we could do it in a non-portable fashion. I just think the
> a_g_r_b prototype is wrong and if we introduce a more complicated
> entropy-gathering mechanism, it's going to need a pool too.
>
> > If APR "should" have an interface to AF_UNIX sockets, that's fine, but
> > that has been unclear.
>
> I think so. I see no reason why it shouldn't have it. In fact a
> lot of APR's socket code is supposing that the socket is IP-based.
> I think that's completely bogus.
>
> > > +#if APR_HAVE_UNIX_DOMAIN
> > > +#define APR_UNIX AF_UNIX
> > > +#endif
> >
> > Note that POSIX supposedly prefers AF_LOCAL to AF_UNIX. But we
> > already have APR_LOCAL :) (What about APR_SOCKET_INET,
> > APR_SOCKET_INET6, APR_SOCKET_LOCAL? Or better yet, AF_INET, AF_INET6,
> > AF_LOCAL? (Sorry, David))
>
> AF_LOCAL or PF_LOCAL aren't defined on Solaris. =) I think there
> are some platforms that have removed AF_ and gone to PF_. So, I
> think it might be good to keep some level of indirection.
>
> > > Index: network_io/unix/sockets.c
> > > ===================================================================
> > > RCS file: /home/cvs/apr/network_io/unix/sockets.c,v
> > > retrieving revision 1.90
> > > + sock->local_addr->salen = sizeof(struct sockaddr_un);
> >
> > this doesn't work perfectly with AF_UNIX... the size as passed to
> > connect() should reflect the real path string once we know it... but
> > there is nothing we can do at this point anyway because we don't know
> > the path string...
> >
> > Your EGD code would need to set salen to SUN_PATH(sa.sunix) before
> > calling apr_connect(). And SUN_PATH() isn't provided everywhere, so
> > grab the one from Stevens' (MHRIP) UNP2eV2.
>
> This leads me to believe that we should have an
> apr_sockaddr_set_path(...) function that hides these implementation
> details.
>
> > > + sock->local_addr->addr_str_len = 108;
> >
> > What about terminating '\0'? Maybe it should be sizeof(sun_path) + 1?
>
> The address is defined to be char[108] in every header file I can
> find, so this seems to be the magic number.
On a FreeBDS I have:
+++
/*
* Definitions for UNIX IPC domain.
*/
struct sockaddr_un {
u_char sun_len; /* sockaddr len including null */
u_char sun_family; /* AF_UNIX */
char sun_path[104]; /* path name (gag) */
};
+++
>
> > Where's the rest? Yeah, we don't need it yet for EGD, but why bother
> > until somebody is ready to implement a bunch of it at once so we can
> > think through the API issues? (starting with (1) should we have
> > something that maps to an AF_UNIX socket on Unix and (2) should that
> > something be APR sockets and (3) what do we do on non-Unix platforms?)
>
> This is why I posted it to the list. =) I think this may get
> implemented and fleshed out as the need arises. This should allow
> it to connect, read, and write to a Unix domain socket. If you
> want to get fancy and do accept and bind on them, you'll need to
> write/correct those functions. -- justin
