CVS update: tng/source/passdb

[Peter Samuelson]

[Joe Doran]
> So the transport mechanisms themselves become transparent. However
> maintaining a flat structure to achieve this is surely more intensive
> and expensive?

I don't understand what you mean by "flat structure" here.  The MSRPC
code needed for NT domain integration is implemented using named pipes
- which is to say, the client connects to an SMB share '\\server\IPC$',
then opens a file '\pipe\{pipename}'.

At this level, the code is client/server.  The client sends requests by
writing to the file it opened, and the server answers the same way.

At a higher level, it's RPC - a MSRPC compiler produces client and
server code that uses the above mechanism implicitly.

> so something akin-
> client->RPC-local  ---> Server --> RPC-remote ( do action ).
> Server -> RPC-Remote --- > Client --> RPC-local.

Crash course in RPC:

Define function foo(), taking two arguments, an int and a char *, and
returning an int.  You declare all this in an interface definition file
("IDL file"), along with the fact that the char * is actually a
variable-length string, which needs to be readable but will not be
modified.

In the client code, you just write x = foo(y, z).  In the server code,
you write function foo().  The IDL file is compiled into a client stub
and a server stub.  You link your client code with the client stub,
which defines a function foo() that handles networking.  You link your
server code with the server stub, which implements networking code
which in turn calls your function foo().

So when the client calls foo(), it is calling a local function defined
by the IDL compiler.  The local function assembles ("marshalls") the
parameters into a generic network structure ("wire format") and sends
this to the server stub, over the network transport.  The server stub
derives ("unmarshalls") the function and arguments, and calls your
server function foo().  foo() returns an int, the server stub marshalls
this int into a wire structure, and sends it back to the client stub,
which unmarshalls it and returns it to the original caller of foo().

In the case of Samba, the server code is not implemented as stubs for
MSRPC functions - just as generic server code that parses the
RPC-marshalled wire data and decodes it on a more or less ad hoc basis,
produced largely by reverse engineering.  The client will never know
the difference, because, under the hood, RPC is really just another
form of client/server.

Peter