apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: [PATCH] Add support for Unix domain sockets
Date Thu, 10 Jan 2002 14:13:56 GMT
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

Mime
View raw message