switch rpc_pipe_open_internal to use NDR marshalling

[Guenther Deschner]

Hi,

currently, the way we handle internal rpc pipes (in RAP to RPC, RPC to RPC
and winbind to RPC scenarios) is highly effective (given the generated
dispatch table) but rather problematic for two reasons:

* Various fields of the IDL structs (all [value(X) elements) are only set
  during NDR push operations and thus remain unset in rpc_pipe_open_internal()
  exchanges.

* Memory allocation (in particular in,out pointers)

Therefor I'd like to push this patch
http://git.samba.org/?p=gd/samba/.git;a=commitdiff;h=d351fc3da3c0a7a5b27435fbcae895eb246a8c0f
which would do change the handling of internal pipes to this model:


Current model:

CLI -> rpccli_INTERFACE_X -> _INTERFACE_X

Proposed model:

CLI -> rpccli_INTERFACE_X -> NDR_PUSH -> api_INTERFACE_X -> NDR_PULL

Client opens pipe using rpc_pipe_open_internal(), no need to provide a
dispatch anymore. The internal dispatch function first does ndr_push the
r->in, calls the generated api_X function like the RPC server does when
accessed from external and finally the dispatch function ndr_pulls out the
result. This means there will be an additional NDR_PUSH(NDR_IN), NDR_PULL(NDR_IN),
NDR_PUSH(NDR_OUT), NDR_PULL(NDR_OUT) for each rpccli_X function using the
internal pipe.

To give some numbers of some raw rpc testing (inside vfstest):

* 100.000 rpccli_samr_GetDomPwInfo requests
	with NDR: 5 sec.
	w/o  NDR: 3 sec.

* 400.000 rpccli_lsa_lookupsids(S-1-5-32-544) requests:
	with NDR: 12 sec.
	w/o  NDR:  4 sec.

I think the performance loss is acceptable given that we would gain much
more correctnes and a cleaner API this way.

Ok, to push ?

Guenther
-- 
Günther Deschner                    GPG-ID: 8EE11688
Red Hat                         gdeschner at redhat.com
Samba Team                              gd at samba.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100708/78c3df6c/attachment.pgp>