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* :) -aaron
