apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Huneycutt <...@duke.edu>
Subject Local sockets
Date Wed, 22 May 2002 21:49:39 GMT
Hello --

I'm looking to use APR and APR-util to make my application much more 
portable.   The basic design of my application is:  a single, 
persistent, threaded daemon with which various small, lightweight 
programs (usually CGI scripts) must share data (two-way).   All the 
daemon's programs are on the same machine, currently, but that could 
change.  These two components together provide the server.  There is 
also a client-side library, which is completely independent of the server.

APR/APR-util includes thread support, DSO support, LDAP support, XML 
support, DBM support, in short, almost all the things I need for my 
application (except Kerberos, but that's already a standard interface 
across platforms, at least with MIT Kerberos; let's ignore MS Kerberos 
and Heimdal).

The socket model seems to be the most elegant way of thinking about the 
connections between the daemon's client apps and the daemon:  the shared 
information (the location of the socket) is constant across all 
applications, and the daemon can have multiple connections via that same 
socket at the same time.   Shared memory requires a different key for 
each segment, so you have the problem of trying to get that conveyed to 
the server daemon.  The applications are NOT children of the server 
daemon, so the proposed apr_spipe_t isn't useful (as far as I understand 
that proposed type).  If there's another way of doing this sanely and 
elegantly without sockets, please let me know.

The data passed between the two components will include sensitive data, 
like passwords, but the responsibility of protecting that data will rest 
on the shoulders of the administrator, so the administrator could set up 
a private network between front-end webservers and the back-end daemon 
server, if he wanted to do complex things with load balancing.  However, 
local sockets are the perfect, simple, lightest-weight solution, for 
those platforms that implement them, and that's currently the only way I 
support doing this connection.  I'd rather not have to implement this 
two different ways for two different platforms, since that would require 
my application to be complex in a way I'd rather it not be.  However, if 
APR had local sockets, I could have a configuration directive like 
<socket type="local" path="..."/> or <socket type="network" 
address="..."/>, and then set up the socket appropriately, with very 
little complexity, and then read from it and write to it in a sane and 
standard way.

I know this has come up on this list before, and nothing was really 
decided, at least on the list.  The argument was made that it was a 
similar situation to IPv6 sockets on, eg, current versions of OS X, or 
Solaris 2.6, or, indeed, certain versions of Windows -- the APR must 
return APR_ENOTIMPL for certain socket types on some platforms, if you 
support IPv6.  I would agree with this, and since AF_UNIX/AF_LOCAL is 
pretty widely supported in the UNIX world and has been for a long time, 
I'd be willing to bet that the percentage of platforms for which you'd 
return ENOTIMPL is much less for AF_UNIX than AF_INET6.  And it's just 
so darn useful!

I hereby get down on my knees beg for support for this type of socket. 
If it is the lack of time to code it that is holding it up, I'll gladly 
take a stab at implementing it. I haven't played much with the internals 
of the code, only the headers with the intent of using the library, but 
I'm more than willing to learn if it means I can make my application 
even more able to wash its hands of platform-specific complexity.

In any case, thank you for making APR.  I was really beginning to worry 
that I'd have to become a Windows programmer to get my application to 
work sanely under Windows. ;)


Karsten Huneycutt                  A casual stroll through a lunatic
kph@duke.edu                          asylum shows that faith does not
http://www.duke.edu/~kph                 prove anything  --Nietzsche

View raw message