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: inetd-type architecture?
Date Wed, 20 Jun 2001 12:55:15 GMT
[this message, which originated from tng-technical@samba-tng.org,
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.

this is an NT convention, and breaking it will be a pain in the

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

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,


> 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 /

so yes, you got it, mark :)


View raw message