apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: Local sockets
Date Thu, 23 May 2002 04:23:02 GMT
At 11:01 PM 5/22/2002, Karsten Paige Huneycutt wrote:
>According to the API posted in
>Message-ID: <20020111115006.K1529@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





Mime
View raw message