apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: [PATCH] Some named pipe hacking...
Date Thu, 21 Jun 2001 16:05:48 GMT
On Thu, Jun 21, 2001 at 05:43:41PM +0200, Luke Kenneth Casson Leighton wrote:
> On Thu, Jun 21, 2001 at 07:44:25AM -0700, Justin Erenkrantz wrote:
> > On Thu, Jun 21, 2001 at 02:35:19PM +0200, Luke Kenneth Casson Leighton wrote:
> > > thanks bill!
> > > 
> > > recommendation.  use the actual expected format for pipename:
> > > pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> > > hidden / constructed by apr.
> > 
> > Can you please give a concrete example why you need this?
> we would like to rewrite TNG's services using APR.
> that includes, but is not limited to:
> a NetBIOS redirector, running on ports 137, 138, 139 and 445
> a NetBIOS Name Server (WINS), running on top of the NetBIOS redirector.
> a Network Neighbourhood server, ditto.
> an SMB server, ditto.
> a LANMAN server, running on top of the SMB IPC$ server,
> which is actually with an interface of \\.\PIPE\LANMAN
> [which is why i am advocating pipes]
> a SAMR server, same thing, running DCE/RPC over \\.\PIPE\samr
> an lsarpc server, same thing
> a NETLOGON server
> a svcctl server
> a srvsvc server
> all of the dce/rpc services are currently bounced out via
> a unix-domain-socket, and i would like to use an APR
> framework for the portability of this project.
> the NetBIOS and SMB ones are currently 'taking over' ports
> 137, 138, 139 and 445, however there are people out there 
> who would like to make a NAL out of this stuff so that
> others can 'join in the fun'.
> > I don't think any of us are seeing why you need to use the Win32 naming
> > conventions for a pipe.  What you are suggesting goes against all of the
> > precedents in APR.  -- justin
> whoops :)  like i said, i am aware that the 'traditional' focus of
> APR has been to emulate unix and make it portable that way.
> lukes

Hi Luke,

IMHO, it is important to keep local and remote semantics distinct. Local
and remote services (by services I mean any form of IPC) are inherently
different beasts. If we allow named pipes to handle both local and
remote connections under the same conditions (errors, assumptions, etc)
than we may run into serious problems with reliability, error recovery,
and we may even expose ourselves to security risks.

If you really want to start handling remote named pipes, I am more in
favor of something like what Justin suggested. That is, perhaps adding
new functions for the specific handling of remote named pipes.

(if I'm off my rocker here, let me know. I can't say I'm that familiar
with the APR code *yet* :)


View raw message