dce/rpc "client" api

Luke Kenneth Casson Leighton lkcl at samba.org
Fri Aug 18 02:42:49 GMT 2000


> I think the purpose of these functions is to provide 
> a means of abstracting the transport layer over which 
> the dce/rpc pdu's are sent.  The dce/rpc client
> would have not notion of whether or not the underlying 
> transport  was tcp or smb.  This is handled by the 
> internals of the functions themselves.

correct.

> Luke will have to answer why you would want the 
> possibilities of multiple transports (other than 
> because of the spec).

exchange client/server.

>  In my mind, "turning on one 
> transport support" would be a command line switch
> or something.  Say "use smb for the dce/rpc connection
> to server 1 and use tcp for the connection to server 2".
> 
> Does this sound right Luke?

yep.

the format of the connection "endpoint" actually contains full info
required to make the decision:

ncatype://server/dcerpcconnectpoint:portnum

e.g:

ncacn_tcp://192.168.138.2/123456789ABCDEF-1234-5678-123456-2:8080

connects using TCP to 192.168.138.2 on port 8080 to service 123456....

e.g:

ncacn_np://server/pipe/netlogon

connects using SMB to server on SMB-IPC$-DCE/RPC pipe NETLOGON.


at present, that's not implemented because i haven't added ncacn_tcp yet
so have no need - yet - of such a sophisticated specification method.

> 
> > The only thing I'm not keen on here is the returning
> > of (void *) as the type of a "con". I know it's the
> > correct abstract data type thing to do, but I'd like
> > to initially see the internal data type of "con" before
> > deciding.
> 
> While this may change, the purpose (as I understand it)
> for a cli_connection is to provide a means of tracking 
> connections to multiple servers (whereas the current 
> behavior of smbclient only allows one connection at a 
> time).  Mostly this shows up in rpcclient.

exactly.

a good example of this is when joining a wksta to a domain.  *two*
connections are required: one to the wksta, the other to the PDC.

>  The 
> cli_connection structs are stored in an array.  Each struct 
> holds enough information to track the cli_state struct
> for a given server.
> 
> Since this is client side code, it is the 
> equivalent of 
> 
> 	net use \\server1\share1
> 	net use \\server2\share2
> 
> 
> struct cli_connection
> {
>         char *srv_name;
>         char *pipe_name;
>         struct user_creds usr_creds;

> 
>         int type;

removed.
 
>         union
>         {
>                 struct ncacn_np *smb;
>                 struct msrpc_local *local;
>         }
>         msrpc;

becomes a void* conn_info and add cli_connect_fns *con_fns.


> 
>         cli_auth_fns *auth;
>         void *auth_info;
>         void *auth_creds;
> };






More information about the samba-technical mailing list