You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Karsten Huneycutt <kp...@duke.edu> on 2002/05/22 23:49:39 UTC
Local sockets
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. ;)
KH
--
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
Re: Local sockets
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, May 22, 2002 at 06:38:01PM -0700, Ryan Bloom wrote:
> Aaron is actually in the middle of creating a stream pipe API for APR.
> This will use Unix Domain Sockets on Unix, and pipes on Windows. While
> APR requires Unix Domain Sockets, they must be done the right way.
Actually, I'm fairly certain that Windows has support for at least simple
data-passing over AF_UNIX/AF_LOCAL sockets, but I'm not sure if it has
the ability to pass file descriptors over those sockets. The ability to
pass file descriptors *and* data is necessary to implement the spipe API
that I posted a month or two ago (and which I'd like to commit as soon
as I have it working on Unix). I've been assured that we'll be able to
implement the spipe API under Windows with something like named pipes,
but it sounds to me like we either need to support both APIs (domain
sockets and spipes) or we need to come up with a way to unify the APIs.
Questions for the Windows gurus:
- Can AF_UNIX/AF_LOCAL sockets be used to pass other descriptors?
- Would it be possible to implement the full AF_UNIX/AF_LOCAL-family socket
functionality on Windows using something like named pipes?
If it interests anyone, I can post a set of features that I think will
be necessary for implementation of a domain socket in APR.
-aaron
RE: Local sockets
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:01 PM 5/22/2002, Karsten Paige Huneycutt wrote:
>According to the API posted in
>Message-ID: <20...@clove.org>
>
>(which is the last mention I can find in the dev@apr.apache.org archives),
>the apr_spipe_t looks _great_ for parent-child IPC, but is in no way meant
>to serve the same function that local sockets serve. Instead, it seems to
>replace/augment pipe(...), not socket(AF_LOCAL, SOCK_STREAM, 0). There is
>no way I can see to get one of the apr_spipe_t's returned from
>apr_spipe_create accessible in another process, save for a fork/exec. As
>I mentioned, the application I'm re-writing does NOT communicate with
>children, but rather, with entirely unrelated processes.
Realize that this is a HUGE shortcoming for Win32, and functionality that
we need addressed for Windows. With no fork() implementation whatsoever,
we need to be able to pass fd's (apr_socket_t's, apr_file_t's and many other
low level objects) between processes, and that would include passing an
apr_spipe_t across processes without an apr_spipe_t already in existence.
To Justin's comment; no, there is no reason for a Unix Domain Socket
object in apr. If it doesn't [can't] extend portability with platform specific
implementation details, then it doesn't belong in apr. E.g. apr has no
reason to implement malloc and free, because malloc and free are
already portable. To the extent that we would create a wrapper around
an already portable type, that is silliness.
And finally a bit about the low level internals. On win32, one process can
use another processes' HANDLE (fd) only if it has DUPLICATE_HANDLE
privs to the other process. The simple answer is to hang onto the handle
returned by CreateProcess(), which already has all rights, and have that
parent process deal with duplication. As far as named pipes, we have the
advantage that security token assumption between pipes ends of the pipe
is pretty trivial. Whether Win32 will support enough semantics to use
sockets in place of named pipes... or has handle and security token passing
mechanisms for either to sufficiently implement spipe as-written is beyond
me at this moment, but I'd be happy to help see to an implementation.
The argument consistently advanced about an spipe style mechanism is
that it would speak process-to-process on the same machine, only between
spipes themselves. We don't appear interested in implementing some
specific mechanic that would be a communication link to non-apr applications.
Samba and many other projects offer platform specific and platform neutral
communications protocols. Aaron proferred spipe to solve specific problems
between httpd processes that will have a terrific, useful impact on win32
implementations, without any regard to external communications.
Bill
Re: Local sockets
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, May 23, 2002 at 12:01:45AM -0400, Karsten Paige Huneycutt wrote:
> According to the API posted in
>
> Date: Fri, 11 Jan 2002 11:50:07 -0800
> From: Aaron Bannert <aa...@clove.org>
> Message-ID: <20...@clove.org>
>
> (which is the last mention I can find in the dev@apr.apache.org archives),
> the apr_spipe_t looks _great_ for parent-child IPC, but is in no way meant
> to serve the same function that local sockets serve. Instead, it seems to
> replace/augment pipe(...), not socket(AF_LOCAL, SOCK_STREAM, 0). There is
> no way I can see to get one of the apr_spipe_t's returned from
> apr_spipe_create accessible in another process, save for a fork/exec. As
> I mentioned, the application I'm re-writing does NOT communicate with
> children, but rather, with entirely unrelated processes.
>
> If apr_spipe_t has been extended to include this sort of functionality,
> could the API be posted again?
Since this is an obvious requirement for spipe to work on Windows where
there is no concept of process inheritance, I would agree that the
original spipe API will have to be extended. I'm open to suggestions
at this point. In a way, the API we write for this will probably be
extended to concepts like shared memory and cross-process mutexes,
which have always been a bit ackward for writing fully portable code.
How will Windows rendezvous with the other process? Perhaps by some
unique name or a file in the filesystem? What needs to be passed
between the processes in order to establish such a connection?
-aaron
Re: Local sockets
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Ryan Bloom" <rb...@covalent.net> wrote:
> Why aren't named pipes usable in your application? APR already has a
> named pipe implementation, which would solve this problem.
On this topic, is there a way to do something like "connect" "accept" on
named pipes as you would do on AF_UNIX sockets?
Pier
RE: Local sockets
Posted by Ryan Bloom <rb...@covalent.net>.
Why aren't named pipes usable in your application? APR already has a
named pipe implementation, which would solve this problem.
Ryan
> Hello --
>
> According to the API posted in
>
> Date: Fri, 11 Jan 2002 11:50:07 -0800
> From: Aaron Bannert <aa...@clove.org>
> Message-ID: <20...@clove.org>
>
> (which is the last mention I can find in the dev@apr.apache.org
archives),
> the apr_spipe_t looks _great_ for parent-child IPC, but is in no way
meant
> to serve the same function that local sockets serve. Instead, it
seems to
> replace/augment pipe(...), not socket(AF_LOCAL, SOCK_STREAM, 0).
There is
> no way I can see to get one of the apr_spipe_t's returned from
> apr_spipe_create accessible in another process, save for a fork/exec.
As
> I mentioned, the application I'm re-writing does NOT communicate with
> children, but rather, with entirely unrelated processes.
>
> If apr_spipe_t has been extended to include this sort of
functionality,
> could the API be posted again?
>
> Thanks!
>
> KH
>
>
> On Wed, 22 May 2002, Ryan Bloom wrote:
>
> > Aaron is actually in the middle of creating a stream pipe API for
APR.
> > This will use Unix Domain Sockets on Unix, and pipes on Windows.
While
> > APR requires Unix Domain Sockets, they must be done the right way.
> >
> > Ryan
> >
> > ----------------------------------------------
> > Ryan Bloom rbb@covalent.net
> > 645 Howard St. rbb@apache.org
> > San Francisco, CA
> >
> > > -----Original Message-----
> > > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > > Sent: Wednesday, May 22, 2002 8:29 PM
> > > To: Karsten Huneycutt
> > > Cc: dev@apr.apache.org
> > > Subject: Re: Local sockets
> > >
> > > On Wed, May 22, 2002 at 05:49:39PM -0400, Karsten Huneycutt wrote:
> > > > 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.
> > >
> > > I agree. I think we should have support for Unix domain sockets
> > > and return APR_ENOTIMPL on those platforms without it. I know
> > > I've posted patches before that do this. You'd have to search
> > > the archives to find them (don't have MsgId's handy, sorry).
> > >
> > > IIRC, the rest of the group was dead-set against this. Perhaps
the
> > > fact that more people are interested will sway them. -- justin
> >
> >
> >
>
> --
> 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
>
RE: Local sockets
Posted by Karsten Paige Huneycutt <kp...@duke.edu>.
Hello --
According to the API posted in
Date: Fri, 11 Jan 2002 11:50:07 -0800
From: Aaron Bannert <aa...@clove.org>
Message-ID: <20...@clove.org>
(which is the last mention I can find in the dev@apr.apache.org archives),
the apr_spipe_t looks _great_ for parent-child IPC, but is in no way meant
to serve the same function that local sockets serve. Instead, it seems to
replace/augment pipe(...), not socket(AF_LOCAL, SOCK_STREAM, 0). There is
no way I can see to get one of the apr_spipe_t's returned from
apr_spipe_create accessible in another process, save for a fork/exec. As
I mentioned, the application I'm re-writing does NOT communicate with
children, but rather, with entirely unrelated processes.
If apr_spipe_t has been extended to include this sort of functionality,
could the API be posted again?
Thanks!
KH
On Wed, 22 May 2002, Ryan Bloom wrote:
> Aaron is actually in the middle of creating a stream pipe API for APR.
> This will use Unix Domain Sockets on Unix, and pipes on Windows. While
> APR requires Unix Domain Sockets, they must be done the right way.
>
> Ryan
>
> ----------------------------------------------
> Ryan Bloom rbb@covalent.net
> 645 Howard St. rbb@apache.org
> San Francisco, CA
>
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > Sent: Wednesday, May 22, 2002 8:29 PM
> > To: Karsten Huneycutt
> > Cc: dev@apr.apache.org
> > Subject: Re: Local sockets
> >
> > On Wed, May 22, 2002 at 05:49:39PM -0400, Karsten Huneycutt wrote:
> > > 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.
> >
> > I agree. I think we should have support for Unix domain sockets
> > and return APR_ENOTIMPL on those platforms without it. I know
> > I've posted patches before that do this. You'd have to search
> > the archives to find them (don't have MsgId's handy, sorry).
> >
> > IIRC, the rest of the group was dead-set against this. Perhaps the
> > fact that more people are interested will sway them. -- justin
>
>
>
--
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
RE: Local sockets
Posted by Ryan Bloom <rb...@covalent.net>.
Aaron is actually in the middle of creating a stream pipe API for APR.
This will use Unix Domain Sockets on Unix, and pipes on Windows. While
APR requires Unix Domain Sockets, they must be done the right way.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: Wednesday, May 22, 2002 8:29 PM
> To: Karsten Huneycutt
> Cc: dev@apr.apache.org
> Subject: Re: Local sockets
>
> On Wed, May 22, 2002 at 05:49:39PM -0400, Karsten Huneycutt wrote:
> > 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.
>
> I agree. I think we should have support for Unix domain sockets
> and return APR_ENOTIMPL on those platforms without it. I know
> I've posted patches before that do this. You'd have to search
> the archives to find them (don't have MsgId's handy, sorry).
>
> IIRC, the rest of the group was dead-set against this. Perhaps the
> fact that more people are interested will sway them. -- justin
Re: Local sockets
Posted by Justin Erenkrantz <je...@apache.org>.
On Wed, May 22, 2002 at 05:49:39PM -0400, Karsten Huneycutt wrote:
> 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.
I agree. I think we should have support for Unix domain sockets
and return APR_ENOTIMPL on those platforms without it. I know
I've posted patches before that do this. You'd have to search
the archives to find them (don't have MsgId's handy, sorry).
IIRC, the rest of the group was dead-set against this. Perhaps the
fact that more people are interested will sway them. -- justin