On Thu, Jun 21, 2001 at 10:53:57AM -0500, William A. Rowe, Jr. wrote: > From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]> > 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. okay. 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 understand). 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, yes. > 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. [great!] ... 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, luke
