You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Andreas Otto <ao...@onlinehome.de> on 2009/01/22 15:19:30 UTC

Porting to APR failed

Dear APR Support Team,

  some time ago I made the strategic decision to port my software:

	http://libmsgque.sourceforge.net/

  to APR by able to use all of the nice features.

  Some days ago I finally start to do this job ... but today I got a massive
  disappointment ...

  You ask why ?

  It's the UNIX Domain Socket issue !!!

  well Unix-Domains are very beautiful in terms of usability

  you only have to create the "sockaddr_un" as part of "sockaddr"
  and you can use the same code you allready written for
  network sockets to use local sockets

  The main advantages are:

	1. 50% faster as network sockets (on linux)
	2. absolute secure -> no network access

 now the problem:

   APR does not support Unix Domain Sockets

 First I couldn't belief it but than I start checking the internet
 and found something suspicious

 1. many user already request UDS Sockets
 2. but the APR team says Windows has no UDS -> it's not cross-platform
	-> we'll not support this

 Now You get my Answer:

  1. It's a problem of MS not supportting UDS and not a problem of UNIX to
      offer them

  2. In fact the MS management decides that they don't want to support
      UDS and using the backdoor of APR they force the UNIX to not support
      them too

  3. There was still a possibility to introduce a non-portable code to offer
      UDS -> that was not done
      -> some members of the APR team force me not to use UDS

  than you remember I will give away part of my knowledeg (using APR)
  and as result they force me to do something what I don't want

 I will not delete my UDS specific code just to use APR

 Now my offter -> You support UDS until 5 Feb 2009 and I'll use your library


mfg

  Andreas Otto








Re: Porting to APR failed

Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:

> Of course, apr_os_sock_put:
> 
> <http://apr.apache.org/docs/apr/1.2/group__apr__portabile.html#g729bd6825dfadd814de2aa602462d838> 

Thanks for this - I had expected to find this under network routines 
rather than portability routines, I should have dug deeper.

Regards,
Graham
--

Re: Porting to APR failed

Posted by Paul Querna <ch...@force-elite.com>.
Graham Leggett wrote:
> Paul Querna wrote:
> 
>> Check out this:
>> <https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/mod_proxy_fdpass.c> 
>>
>>
>> It provides a few functions and boxes a UDS in and out of an apr_socket.
> 
> Does a mechanism exist to create an apr_socket_t from a given 
> pre-existing fd, possibly given to you by another library or non-apr 
> piece of code?
>

Of course, apr_os_sock_put:
 
<http://apr.apache.org/docs/apr/1.2/group__apr__portabile.html#g729bd6825dfadd814de2aa602462d838>

Re: Porting to APR failed

Posted by Graham Leggett <mi...@sharp.fm>.
Paul Querna wrote:

> Check out this:
> <https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/mod_proxy_fdpass.c> 
> 
> 
> It provides a few functions and boxes a UDS in and out of an apr_socket.

Does a mechanism exist to create an apr_socket_t from a given 
pre-existing fd, possibly given to you by another library or non-apr 
piece of code?

Regards,
Graham
--

Re: Porting to APR failed

Posted by Paul Querna <ch...@force-elite.com>.
Andreas Otto wrote:
> Dear APR Support Team,
> 
>   some time ago I made the strategic decision to port my software:
> 
> 	http://libmsgque.sourceforge.net/
> 
>   to APR by able to use all of the nice features.
> 
>   Some days ago I finally start to do this job ... but today I got a massive
>   disappointment ...
> 
>   You ask why ?
> 
>   It's the UNIX Domain Socket issue !!!
> 
>   well Unix-Domains are very beautiful in terms of usability
> 
>   you only have to create the "sockaddr_un" as part of "sockaddr"
>   and you can use the same code you allready written for
>   network sockets to use local sockets
> 
>   The main advantages are:
> 
> 	1. 50% faster as network sockets (on linux)
> 	2. absolute secure -> no network access
> 
>  now the problem:
> 
>    APR does not support Unix Domain Sockets

Check out this:
<https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/mod_proxy_fdpass.c>

It provides a few functions and boxes a UDS in and out of an apr_socket.

-Paul


Re: Porting to APR failed

Posted by Mathias Brossard <ma...@opentrust.com>.
Lucian Adrian Grijincu wrote:
> On Thu, Jan 22, 2009 at 5:55 PM, Mathias Brossard
> <ma...@opentrust.com> wrote:
>> Andreas Otto wrote:
>>>    APR does not support Unix Domain Sockets
>>        You *can* use Unix Domain Sockets with APR, it's just not as easy as I think
>> (and apparently you do too) it should be. I'll forward you in private the thread
>> I initiated on the same topic (it's from this list around 2006/04/27).
> 
> For archiving reasons and helping others that will search for "how to
> use af_unix unix domain sockets with apr", it would be better to send
> the link to the message (mail-archives.apache.org, or another archiver
> subscribed to APR) as a reply to this thread on the list :)

You're right. I didn't find an obvious way to link to a thread so I'll link to
the most important mail (which also quotes mine) :
http://mail-archives.apache.org/mod_mbox/apr-dev/200604.mbox/<7e...@mail.gmail.com>

>From what I understood from the mail was that I should create my socket on my
own and then use apr_os_sock_put to shove it into an apr_socket. If memory
serves me right, it worked.

Sincerely,
-- 
Mathias Brossard

Re: Porting to APR failed

Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On Thu, Jan 22, 2009 at 5:55 PM, Mathias Brossard
<ma...@opentrust.com> wrote:
> Andreas Otto wrote:
>>    APR does not support Unix Domain Sockets
>
>        You *can* use Unix Domain Sockets with APR, it's just not as easy as I think
> (and apparently you do too) it should be. I'll forward you in private the thread
> I initiated on the same topic (it's from this list around 2006/04/27).

For archiving reasons and helping others that will search for "how to
use af_unix unix domain sockets with apr", it would be better to send
the link to the message (mail-archives.apache.org, or another archiver
subscribed to APR) as a reply to this thread on the list :)

-- 
 .
..: Lucian

Re: Porting to APR failed

Posted by Mathias Brossard <ma...@opentrust.com>.
Andreas Otto wrote:
>    APR does not support Unix Domain Sockets

	You *can* use Unix Domain Sockets with APR, it's just not as easy as I think
(and apparently you do too) it should be. I'll forward you in private the thread
I initiated on the same topic (it's from this list around 2006/04/27).

Sincerely,
-- 
Mathias Brossard

Re: Porting to APR failed

Posted by Andreas Otto <ao...@onlinehome.de>.
Am Donnerstag 22 Januar 2009 16:13:30 schrieb Gordon Henriksen:
> On 2009-01-22, at 09:19, Andreas Otto wrote:
> >  Some days ago I finally start to do this job ... but today I got a
> > massive
> >  disappointment ...
> >
> >  You ask why ?
> >
> >  It's the UNIX Domain Socket issue !!!
> >
> > [rant snipped]
> >
> >
> > Now my offter -> You support UDS until 5 Feb 2009 and I'll use your
> > library
>
> Hello Andreas,
>
> Please remember that this is an open source project and that you are
> addressing a team of volunteer contributors, all of whom have
> different priorities from you. Unless they happen to be in your
> employ, you have no standing to demand anything of any of them. If you
> need a feature, you have several straight-forward options to get it
> implemented:
>
>   1. Do it yourself.
>   2. Pay someone to do it for you.
>   3. Try to convince someone that it is important.
>
> It seems to me that your message is counterproductive to any of these.
>
> If upstream actively does not want the feature, as may be the case
> here, you have again options. You can maintain a patch locally, which
> APR makes quite practicable and entirely legal. You can branch the
> product. You can work around the limitation in your own codebase. Or,
> of course, you can opt not to use the product at all.
>
> APR already provides abstractions for features which may not be
> available on all platforms, so I would share your surprise if a
> thoughtfully implemented patch providing Unix-domain socket support
> were rejected. However, such a patch must exist before it can be
> rejected.
>
> Thank you,
> Gordon

Hi,

 I allready have a working application which use TCP and UDS sockets together
 with socketpair ....

the problem is:

  I want to make the code more easy (this mean less code , less complicate)
  I don't want to keep the OLD socket code arrount for UDS and translate the
  TCP code to APR.

  For me not suporting UDS is the definitly killer for APR
  -> I really don't understand this becaue it is very simple to implement ...
  -> It is just the sockaddr struct which is different nothing else !!!

this is my code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><
static void
sUdsFillAddress (
  struct UdsS * const uds
)
{
  strcpy (uds->sockaddr.sun_path, uds->file->cur.C);
  uds->sockaddr.sun_family = AF_UNIX;
}
---------------------------------------------------------------------------------------------------------
static enum MqErrorE
sTcpCreateSocketAddress (
  struct TcpS const * const tcp,    /* the tcp object in duty */
  struct sockaddr_in *sockaddrPtr,  /* Socket address */
  struct MqBufferS * const host,    /* Host.  NULL implies INADDR_ANY */
  struct MqBufferS * const port     /* port number */
)
{

  struct hostent *hostent;      /* Host database entry */
  MQ_INT portU2;

  // 1. convert port number into UMQ_INT
  MqErrorCheck (sTcpSockGetPort (tcp, port, &portU2));

  // 2. fill sockaddrPtr
  (void) memset ((void *) sockaddrPtr, '\0', sizeof (struct sockaddr_in));
  sockaddrPtr->sin_family = AF_INET;

  sockaddrPtr->sin_port = htons ((unsigned short) (portU2 & 0xFFFF));
  if (host->cursize) {
    MQ_STR hoststr;
    MqErrorCheck (MqBufferGetC (host, MqBufferGetC_static, &hoststr));
    if (SysInetAton (host->error, hoststr, &sockaddrPtr->sin_addr) == 
MQ_ERROR) {
      MqErrorReset (host->error);
      MqErrorCheck (SysGetHostByName (host->error, hoststr, &hostent));
      memcpy ((void *) &sockaddrPtr->sin_addr.s_addr,
              (void *) hostent->h_addr_list[0], (size_t) hostent->h_length);
    }
  } else {
    sockaddrPtr->sin_addr.s_addr = htonl (INADDR_LOOPBACK);
  }

  return MQ_OK;                 /* Success. */

error:
  return MqErrorStack (MQ_ERROR_S);
}


Re: Porting to APR failed

Posted by Nick Kew <ni...@webthing.com>.
On 22 Jan 2009, at 15:13, Gordon Henriksen wrote:

> If upstream actively does not want the feature, as may be the case  
> here,

The evidence to support that is sparse: the OP cited what was in all  
probability
a throwaway remark by one poster to a mailinglist.  Unless he can cite
evidence to the contrary.

 > [chop more good advice]

-- 
Nick Kew

Re: Porting to APR failed

Posted by Gordon Henriksen <go...@me.com>.
On 2009-01-22, at 09:19, Andreas Otto wrote:

>  Some days ago I finally start to do this job ... but today I got a  
> massive
>  disappointment ...
>
>  You ask why ?
>
>  It's the UNIX Domain Socket issue !!!
>
> [rant snipped]
>

> Now my offter -> You support UDS until 5 Feb 2009 and I'll use your  
> library

Hello Andreas,

Please remember that this is an open source project and that you are  
addressing a team of volunteer contributors, all of whom have  
different priorities from you. Unless they happen to be in your  
employ, you have no standing to demand anything of any of them. If you  
need a feature, you have several straight-forward options to get it  
implemented:

  1. Do it yourself.
  2. Pay someone to do it for you.
  3. Try to convince someone that it is important.

It seems to me that your message is counterproductive to any of these.

If upstream actively does not want the feature, as may be the case  
here, you have again options. You can maintain a patch locally, which  
APR makes quite practicable and entirely legal. You can branch the  
product. You can work around the limitation in your own codebase. Or,  
of course, you can opt not to use the product at all.

APR already provides abstractions for features which may not be  
available on all platforms, so I would share your surprise if a  
thoughtfully implemented patch providing Unix-domain socket support  
were rejected. However, such a patch must exist before it can be  
rejected.

Thank you,
Gordon


Re: Porting to APR failed

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Lucian Adrian Grijincu wrote:
> On Thu, Jan 22, 2009 at 4:19 PM, Andreas Otto <ao...@onlinehome.de> wrote:
>> Dear APR Support Team,
> 
> Is there such a team? This is the APR *development* list (that's where
> the "dev" in dev@apr.apache.org comes from).

Was gonna say... look at the LICENSE.  No warranty.

>>  It's the UNIX Domain Socket issue !!!
> 
> You can do what others have already done: write a wrapper for some of
> APR's functions in which you want to use AF_UNIX sockets and use &
> distribute the wrapper with your code.

e.g. I needed access to the registry, nobody at the APR project backed up
my desire / need to have this functionality, but it works perfectly well
over at httpd, see;

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/include/ap_regkey.h
  http://svn.apache.org/repos/asf/httpd/httpd/trunk/os/win32/ap_regkey.c

No weeping, or wailing, or gnashing of teeth.


Re: Porting to APR failed

Posted by Lucian Adrian Grijincu <lu...@gmail.com>.
On Thu, Jan 22, 2009 at 4:19 PM, Andreas Otto <ao...@onlinehome.de> wrote:
> Dear APR Support Team,

Is there such a team? This is the APR *development* list (that's where
the "dev" in dev@apr.apache.org comes from).


>  It's the UNIX Domain Socket issue !!!

You can do what others have already done: write a wrapper for some of
APR's functions in which you want to use AF_UNIX sockets and use &
distribute the wrapper with your code.

-- 
 .
..: Lucian

Re: Porting to APR failed

Posted by Mladen Turk <mt...@apache.org>.
Andreas Otto wrote:
> Dear APR Support Team,
> 
>   some time ago I made the strategic decision to port my software:
> 
> 	http://libmsgque.sourceforge.net/
> 
>   to APR by able to use all of the nice features.
> 
>   Some days ago I finally start to do this job ... but today I got a massive
>   disappointment ...
> 
>   You ask why ?
> 
>   It's the UNIX Domain Socket issue !!!
> 
>   well Unix-Domains are very beautiful in terms of usability
> 
>   you only have to create the "sockaddr_un" as part of "sockaddr"
>   and you can use the same code you allready written for
>   network sockets to use local sockets
> 
>   The main advantages are:
> 
> 	1. 50% faster as network sockets (on linux)
> 	2. absolute secure -> no network access
> 
>  now the problem:
> 
>    APR does not support Unix Domain Sockets
>

Perhaps it will in the future.
Here is a patch that allows to do that.
The apr_sockadr_local_get could be included
inside apr_sockaddr_info_get and use hostname
for filename.

Not sure if some addr functions need some extra
check for AF_UNIX, since they'll probably
fail or return some junk. Nevertheless
I doubt they are useful anyhow for domain sockets.

I've tested the API, and bind/connect/accept
works fine. However probably there will be
needed some unlik callback on bind.

Regards
-- 
^(TM)