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: [PATCH] Some named pipe hacking...
Date Sat, 23 Jun 2001 19:49:16 GMT
On Thu, Jun 21, 2001 at 10:53:57AM -0500, William A. Rowe, Jr. wrote:
> From: "Luke Kenneth Casson Leighton" <lkcl@samba-tng.org>
> Sent: Thursday, June 21, 2001 7:35 AM
> > thanks bill!
> > 
> > recommendation.  use the actual expected format for pipename:
> > pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> > hidden / constructed by apr.
> APR is here to make folks cross-plaform development blindingly simple.  
> And (for the most part) it does.  What you've proposed makes things far 
> more difficult to follow.  Named unix pipes are local, no?  

i actually know very little about named unix pipes.  but afaict,
yes, _unix_ named pipes are a local-only concept.

and i advise against using unix pipes to implement this proposal,
which is to implement *nt* named pipes, which are, as you
can see from the OS/2 and NT developer SDK documentation, are
totally different from un ix named pipes.

> So the _Lowest 
> Common Denominator_ says that our APR namedpipe implementation is to create 
> local pipes.
only if youconsider unix named pipes to be the same as nt named
pipes, which they certainly aren't.


i have a question.  is it unreasonable to expect Unix developers
to learn an API that is identical in functionality to an NT
(and an OS/2) one?

think through what you are proposing.

i want to implement NT named pipes, using or _in_ APR.

NT already _has_ NT namedpipes (and so does OS/2).  so,
you are proposing to 'shackle' the NT named pipes to 'local only',
because some unix developers can't be ... well ... uhh...
okay, i'll be polite, but it's the same thing, 'might be confused'
by something that isn't a unix API.

and then, you expect me to implement 'remote' named pipes
as a shim on top of a crippled, perfectly good remote
named pipes implementation?  [but not in apr, because it's
considered too complex]

*blink* uhn? :) :)

i think that anyone looking at such a codepath, trying
to work out what's going on, is going to do a double-take
and get even more confused than if the nt impl. of apr_namedpipes
just went straight through to the NT one and the unix one
used some external proxying service to emulate the remote bits.
IF they WANTED the remote bits.

> If you want to create a cross-machine pipe architecture, then you must add
> another function with char *machine, char *pipename semantics.  If you have
> at least a rough outline of the implementation for this on unix.

rough?  better than that, i have working code.  it's in use in
samba tng today, has been for about a year and a half.

it duplicates the functionality of NT named pipes.

i was hoping to use apr to make a better version of the code
in tng, having learned from the first impl.

> One problem with using Netbios in any public environment is that the vast
> majority of operators will clamp down on the Netbios ports of any public
> machine outside the firewall.  This is for pretty good reasons, given the
> paucity of security on that interface.
yes.  there are a couple of other similar situations where
proposals - or actual implementations - have provided proxying
of other transports onto other transports [explanation: NetBIOS
is actually a full transport, but no-one implements it on
its own, now, only the proxied versions]

one is DCE/RPC over HTTP [this was added to NT for exchange's
benefit: it runs on port 689 and there is an IIS component
that is enabled BY DEFAULT ON NT5 argh argh that proxies this
to port 80].  so, now all of your entire NT domain infrastructure,
including exchange etc, is vulnerable to dce/rpc-related
security attacks because ms wanted their customers to be
able to read email through a firewall.  greaaat.

the other is the new TCP over HTTP proposal (a draft rfc i

but anyway.  so... yes?  and?  yes, i agree with you.  i'd
even recommend it.  the ports are 137, 138 and 139.  if you
want to shut down SMB over TCP too, that's on port 445.
and if you want to shut down dce/rpc portmapper, that's
on 135.  and the dce/rpc over http?  port 689, and then
disable the redirector component too, in IIS.

... but despite all this, i don't see it as a relevant point
to make as a reason not to fully implement NT named pipes.

> If you are looking for a cross-machine semantic,


> the underlying support must also be cross-platform.  

yes.  now i know _you_ know that.

> If you propose Samba for this, 

[no i don't: see below]

> then fine, let's start discussing that.

...  what i actually want to propose is a project that
sander and i have been considering: an alternative implementation
to samba.

there _aren't_ any open source alternatives to samba,
and sander and i would both like to implement one - as
an Apache Software Foundation project.

now, given microsoft's recent announcement regarding
their SDK - You May Not Implement Or Use This In
Open Source Projects Except BSD Ones, that looks like
being an increasingly attractive option.

anway.  i apologise in advance for holding most of the
designs for an approximately... 2 million lines of code
project [series] in my head.  i get a bit confused
occasionally about which bits i've actually explained to people.

people ask for justifications, but they're like... six months
down the line, and i've already planned _now_ for _then_.

so yes, a full cross-machine, cross-platform NT-like
named pipe implementation _is_ important - no, it's
absolutely critical - to the plans and designs that
i wish to achieve.

and the whole reason that i am not speaking to those idiots
who now consider themselves responsible for samba's
development is because they couldn't 'get' this simple
concept [an NT-like named pipe implementation], but wanted to
keep samba as one, big monolithic program.

170 THOUSAND lines of code - one program - and *only
getting bigger!*.  by the time they are done, which at
the rate they're going will be when NT is retired,
that will probably be about 400 to 500 thousand lines.

utterly, utterly mad.

> If this implementation is strictly for NT, please don't bloat code with things
> you can do trivialy and faster with the native API.

regarding xvl, which i am also wanting to use APR for;
the code i have is specifically restricted to unix (xvl) _because_
there is no appropriate inter-process client/server code available
for me to use in apr.

for me, xvl is a really cool little project that helps keep
me going, and also is a good 'test' case [only 16,000 LOC].

i think i will actually go out and get very very drunk when
xvl compiles and works in apache on NT :)  and i think
the php people would be very happy too: currently, php
on NT can *only* be run as a cgi-bin stand-alone exe,
which is a bit mad.  an NT namedpipe API in apr would
go a long, ong way to making php on NT more efficient.

all best,


View raw message