[this message, which originated from [EMAIL PROTECTED], is cross-posted from apr dev and samba tech. the relevance to apr dev is the issues / justification of creating an apr NamedPipe interface - exactly mirroring the NT NamedPipe one _not_ the unix namedpipe one. luke]
On Wed, Jun 20, 2001 at 09:28:31AM +0100, Mark Cave-Ayland wrote: > Hi everyone, hi mark :) > Just thought I'd add my ideas while people are deciding what to > break after the release of 2.6.1 :) > > Would it be an idea to give TNG a similar architecture to inetd? > That is, to have a 'superdaemon', say called tngd, that handles all > the SMB connections, and passes the raw pipe data over stdin to the > child daemon process. The allocation of pipes to executables could > be done by a tngd.conf file, e.g. like it. > > # Example tngd.conf > > //./pipe/samr /opt/samba-tng/samr > //./pipe/spoolss /opt/samba-tng/spoolss > //./pipe/foo /opt/samba-tng/foo the backslashes need to be the other way round for the NT-like bits. \\.\pipe\samr. this is an NT convention, and breaking it will be a pain in the neck. following this convention will also make it easier to use [the proposed] apr_named_pipe_create() and apr_named_pipe_transact(). > ..and so on. I guess any other namespace is a reference to a file > and should be passed by default to smb. i was wondering. might it be better to put real functionality behind srvsvcd? after all, what you are describing is srvsvcd's job. srvsvcd's job is also to handle the dependencies for service startup. we could look at the linux kernel 'Calculating module dependencies' code to get an algorithm to work out the startup order. > Then if anyone wrote a windows program to send "Hello World" to the > named pipe 'foo' on a TNG machine then it would appear on stdin > when tngd launched the command "/opt/samba-tng/foo //./pipe/foo". The > only downside I can see with this is that it requires one process per > pipe access from each client. yes. i honestly don't see this as a downside. if it's a really heavy downside, well, then the implementor of the daemon must do a threaded architecture, or a single-process model, rather than the existing 'fork' one. we _really_ need to use APR. > But then again with a > marshalling/unmarshalling library the programs should be very > lightweight and could potentially terminate as soon as the RPC is > serviced. correct. all dce/rpc services - all the good ones, anyway [so that *doesn't* include exchange, that is _so_ badly designed or rather it's the way it's used that is bad, not the interfaces themselves ] - are designed *knowing* that a function will take of the order of milliseconds or tens of milliseconds to get a response. worrying about delays by forking, memcpys etc, is really, _really_ not going to help you [okay, unless your server is hammered by thousands or tens of thousands of DCE/RPC connections, _then_ you have to worry about it :)] if you are used to optimising code that deals with 2nd-level cache but must operate out of a hard disk and that optimisation looks pretty pointless, then now extend that to optimising code to deal with a 2nd-level cache on your processor but it's actually going over a network, and you get some idea of how ridiculous it is to consider optimising DCE/RPC code for speed :) about 4 orders of magnitude away! totally different ball game, totally different programming techniques. > Of course, the advantages of this would be that some changes could be made > without recomiling TNG, e.g. changing the //./pipe/samr entry to point > to an LDAP-aware version. Also additional RPCs could be easily added, > e.g. winpopup could be handled by a //./mailslot/messgnr entry. correct! that was the *whole* point of the TNG architecture. mister dr andrew tridgell, bless him, knows better [obviously]. but that's his problem to deal with. > Knowing all the people on this list, this has probably been already > suggested, yes. > but then dismissed for a very good reason.... no, it wasn't. there are in fact four totally separate samrd daemons in various stages of completion / completeness. you must run only one of them. all of them use [listen on] \\pipe\samr in a ux-dom-sock. the TNG ux-dom-sock interface, which is effectively functionally identical and i _mean_ identical to NT Named Pipes, right down to a means to transfer NT security context between the client and server, is the dividing line to ensure no other components / services are affected by an implementation _of_ another component / service. so yes, you got it, mark :) luke
