outsourcing DCE/RPC to alternate programs - runtime config option

tridge at samba.org tridge at samba.org
Sat Dec 11 23:57:27 GMT 2004


Michael,

 > We are using ncacn_ip_tcp.  Does Samba 4 have an IDL compiler that is
 > compatable with DCE?  If so the RPC portion of the Samba product could be
 > very useful to ourselves and many others.  Thanks.

The IDL compiler in Samba4 (called "pidl") is not completely
compatible with the DCE compiler. 

It is sufficiently close that we have working IDL for a large number
of rpc interfaces that Microsoft servers typically provide, such as
samr, netlogon, lsarpc, winreg etc, but there are certainly things you
can do with the DCE IDL compiler that cannot be done with pidl. That
said, there are also things that can be done with pidl that cannot be
done with the DCE compiler. 

Most of these "extras" in pidl are things to make working with RPC
easier, such as auto-generating pretty printers for all IDL
structures, and automatic handling of string format conversion, but
some of them are minor IDL extensions, such as the ability to handle
non-aligned structures (allowing us to define the core DCE/RPC frames
as IDL in dcerpc.idl, which DCE cannot do).

Probably the best thing for you to do is look at
  http://samba.org/ftp/unpacked/samba4/source/librpc/idl/ 
to see the IDL that is currently in Samba4. See source/torture/rpc/
for our test suites.

Over time I expect that pidl will be taught to handle more and more of
the DCE IDL syntax, as we run into situations in our effort to build a
full ADS server that require more IDL constructs. I would also not be
surprised if someday we dump pidl and build yet another IDL
compiler. It's working well for us now, but it is not by any means a
"good" compiler (my inexperience in writing compilers really shows up
I'm afraid). Luckily it is very small (just 8k lines of perl code), so
getting starting with making extensions to it is probably a lot easier
than working with the FreeDCE compiler.

Probably the biggest issue for you will be the APIs that get
generated. We don't build a client/server API that is at all
compatible with the DCE runtime. For example, we generate code that
expects a RPC server to look like this for the well known
"samrConnect" call:

  NTSTATUS samr_Connect(struct dcesrv_call_state *dce_call, TALLOC_CTX *mem_ctx,
                        struct samr_Connect *r)

where struct samr_Connect is generated to look like this:

  struct samr_Connect {
	struct {
		uint16 *system_name;
		uint32 access_mask;
	} in;
	struct {
		struct policy_handle *connect_handle;
		NTSTATUS result;
	} out;
  };

This is quite different to the DCE approach, which would produce
something more like this:

  NTSTATUS Connect(uint16 *system_name, 
                   uint32 access_mask, 
                   struct policy_handle *handle);

We have some pretty good reasons for using the different API, and it
has worked out very well for us, but if you are migrating existing
code you'd either need a bunch of shim functions or you'd need to
rewrite all the entry points.

You should also be warned that while the Samba4 rpc code is working
well for us, it is not yet a mature project. There is no official
release yet, just a public source code repository.

Cheers, Tridge


More information about the samba-technical mailing list