apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: More migration of code from httpd to apr-util
Date Thu, 21 Jun 2001 15:37:16 GMT
On Thu, Jun 21, 2001 at 07:58:07AM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 21, 2001 at 02:54:43PM +0200, Luke Kenneth Casson Leighton wrote:
> > what i have been hinting at, and planning, is that i will actually
> > provide, with the TNG architecture, is the FULL \\servername\\PIPE\pipename
> > functionality.  yes, that's right: i will write code that redirects
> > to TNG, which will farm out the data over SMB over to a remote
> > system FOR you.
> > 
> > that's right: a unix apr application will be able to connect to
> > a *remote* NT apr server.  that's *remote* platform independence,
> > not just local platform independence.
> > 
> > and if you don't expose the full pipe-name in the APR api, i can't
> > do that.
> 
> Heh, you attempted to answer my previous question before I asked it.

whoopsie :)

> Teaches me to read all of your posts before replying to any of them.
 
:) me too, i think i have enough experience at the consequences of
not reading ahead, now :)

> But, aren't named pipes typically local-only?  

server-side, they can be nothing _but_ local-only.

client-side, no.  it's possible to connect to
\\servername\PIPE\samr and make direct dce/rpc requests
to it, if you feel so inclined.

or to \\servername\PIPE\LANMAN, or whatever is running or
whatever someone chooses to make run, listening on a pipe.


> Maybe what you need is 
> something outside of traditional named pipes (i.e. "remote" named 
> pipes).  Add the named pipe code and then add a "special" function in 
> apr that allows you to get at the full namespace, if so desired.  

.... which is why i'm advocating the NAL because then 'hooking' in
'special' functions becomes a trivial matter.


*thinks.

*thinks some more*.

AH!  bill, i think you're right, regarding server-side, about
specifying _just_ the pipe name.

client-side, i'm not so sure.

does anyone have any working NT client / server pipe apps?
i'd be a lot happier / lot more confident if i could
see coding examples, native NT code.

and bill, do you envisage calling apr_namedpipe_create() on
_both_ the client-side _and_ the server-side, a bit like
when you create a socket?

because if so, i think the full syntax \\server\pipe\pipename
will be needed, and if you go 'server-side', then server
has to be '.' otherwise it's an error.


> But, 
> it seems that this "remote" named pipe would only be available with an 
> SMB library - which is TNG's domain, not APR's.  

i envision that anyone could write a 'redirector' daemon,
and without such a daemon running, you simply don't _get_
the ability of client-side programs to connect to remote
pipes, you can only connect to \\.\PIPE\pipename.


> I guess I'm unsure whether named pipes will work from other machines on
> other platforms.  If this works only with Win32 (or having an SMB
> protocol to handle this on the Unix end), 

or your own 'redirector' daemon that runs on the client and on the
server, but to be honest, doing it via SMB is the simplest option:
take a look at the odbc-odbc-bridges that are out there, the principle
is sound - for only _one_ server - but as soon as you get to multiple
servers it becomes completely unworkable.

> this seems something that TNG
> could add outside of the apr space.  -- justin

OS/2 also supports TransactNamedPipe and friends, i asked :)

all best,

luke

p.s you know, i really should just go and code this up :)

Mime
View raw message