apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] Add support for Unix domain sockets
Date Sat, 05 Jan 2002 03:22:27 GMT
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.

> 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


Mime
View raw message