switch rpc_pipe_open_internal to use NDR marshalling

simo idra at samba.org
Thu Jul 8 08:31:23 MDT 2010


On Thu, 2010-07-08 at 14:26 +0200, Guenther Deschner wrote:
> 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 ?

+1

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>



More information about the samba-technical mailing list